>From 607fcd042071b0dd8b4deeafefb3c1405540a320 Mon Sep 17 00:00:00 2001 From: Shawn Wells Date: Fri, 16 Nov 2012 07:08:02 -0500 Subject: [PATCH 06/13] DISA FSO provided copy editing of RHEL6/input/services/dns.xml DISA FSO provided copy editing of RHEL6/input/services/dns.xml --- RHEL6/input/services/dns.xml | 30 +++++++++++++++--------------- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git a/RHEL6/input/services/dns.xml b/RHEL6/input/services/dns.xml index 4e700b7..5550530 100644 --- a/RHEL6/input/services/dns.xml +++ b/RHEL6/input/services/dns.xml @@ -34,7 +34,7 @@ implementation flaws and should be disabled if possible. Uninstall bind Package To remove the bind package, which contains the -named service, run the following command: +named service, run the following command.
# yum erase bind
@@ -68,21 +68,21 @@ machines which act as organizational DNS servers. Run DNS Software in a chroot Jail -Install the bind-chroot package: +Install the bind-chroot package.
# yum install bind-chroot
-Place a valid named.conf file inside the chroot jail: +Place a valid named.conf file inside the chroot jail.
# cp /etc/named.conf /var/named/chroot/etc/named.conf
 # chown root:root /var/named/chroot/etc/named.conf
 # chmod 644 /var/named/chroot/etc/named.conf
Create and populate an appropriate zone directory within the jail, based on the -options directive. If your named.conf includes: +options directive. If your named.conf includes.
options {
 directory "/path/to/DIRNAME ";
 ...
 }
-then copy that directory and its contents from the original zone directory: +then copy that directory and its contents from the original zone directory.
# cp -r /path/to/DIRNAME /var/named/chroot/DIRNAME
-Edit the file /etc/sysconfig/named. Add or correct the line: +Edit the file /etc/sysconfig/named. Add or correct the line.
ROOTDIR=/var/named/chroot
Chroot jails are not foolproof. However, they serve to make it more @@ -134,7 +134,7 @@ DNS data.
Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. On the external nameserver, edit /etc/named.conf. Add or correct the -following directives: +following directives.
options {
   allow-query { any; };
   recursion no;
@@ -145,7 +145,7 @@ zone "example.com " IN {
 };
On the internal nameserver, edit /etc/named.conf. Add or correct the following directives, where SUBNET is the numerical IP representation of your -organization in the form xxx.xxx.xxx.xxx/xx: +organization in the form xxx.xxx.xxx.xxx/xx.
acl internal {
   SUBNET ;
   localhost;
@@ -190,7 +190,7 @@ Separate machines should be used to fill these two functions whenever possible.
 separate physical machines, run BIND9 and simulate this feature using views.
 Edit /etc/named.conf. Add or correct the following directives (where
 SUBNET is the numerical IP representation of your organization in the form
-xxx.xxx.xxx.xxx/xx):
+xxx.xxx.xxx.xxx/xx).
 
acl internal {
   SUBNET ;
   localhost;
@@ -237,7 +237,7 @@ this server as a general-purpose nameserver.
 via zone transfer from the primary server?  If not, follow the instructions in
 this section. If so, see the next section for instructions on protecting zone
 transfers.
-Edit /etc/named.conf. Add or correct the following directive:
+Edit /etc/named.conf. Add or correct the following directive.
 
options {
   allow-transfer { none; };
   ...
@@ -257,15 +257,15 @@ disabled to avoid the potential for abuse.
 Authenticate Zone Transfers
 If it is necessary for a secondary nameserver to receive zone data
 via zone transfer from the primary server, follow the instructions here.  Use
-dnssec-keygen to create a symmetric key file in the current directory:
+dnssec-keygen to create a symmetric key file in the current directory.
 
# cd /tmp
 # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com
 Kdns.example.com .+aaa +iiiii
This output is the name of a file containing the new key. Read the file to find -the base64-encoded key string: +the base64-encoded key string.
# cat Kdns.example.com .+NNN +MMMMM .key
 dns.example.com IN KEY 512 3 157 base64-key-string
-Edit /etc/named.conf on the primary nameserver. Add the directives: +Edit /etc/named.conf on the primary nameserver. Add the directives.
key zone-transfer-key {
   algorithm hmac-md5;
   secret "base64-key-string ";
@@ -275,7 +275,7 @@ zone "example.com " IN {
   allow-transfer { key zone-transfer-key; };
   ...
 };
-Edit /etc/named.conf on the secondary nameserver. Add the directives: +Edit /etc/named.conf on the secondary nameserver. Add the directives.
key zone-transfer-key {
   algorithm hmac-md5;
   secret "base64-key-string ";
@@ -314,7 +314,7 @@ key files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM
 Disable Dynamic Updates
 Is there a mission-critical reason to enable the risky dynamic
 update functionality? If not, edit /etc/named.conf. For each zone
-specification, correct the following directive if necessary:
+specification, correct the following directive if necessary.
 
zone "example.com " IN {
   allow-update { none; };
   ...
-- 
1.7.1