Lab 4 The Domain Name System
Goal: To install and configure a DNS server
System Setup: Throughout this and subsequent labs, you will configure your system with various services. For each of these leave SELinux and the firewall enabled, and add the ports necessary for these services.
All references to stationX or domainX should use your station number as X. For example, the person at station 1 should use station1 and domain1.
Situation: Your company's DNS administrator has asked you to set up a name server for your department and has already added the appropriate glue record(s) in the company's main DNS (server1). Henceforth all DNS queries for your
department, domainX, have been delegated to your machine. Additional specifications include:
• Your machine should continue to use DHCP addressing for its IPv4 address.
• All hosts in your department are located in the DNS domain domainX.example.com, where X is your station number. There are
20 hosts in this domain, each named station1 through station20. The IPv4 addresses for these hosts are 192.168.0.1 through
192.168.0.20.
• Your server should only allow queries from itself and from other hosts in the departmental subnet, 192.168.0.0/24. The corporate standard further specifies that all DNS servers must run in a chrooted environment for security.
• Your server should forward all queries to server1 for domains outside of example.com.
• For troubleshooting and testing purposes, you should be able to use dig and host to perform zone transfers from your own station.
domainX happens to be located in a branch office, so upon successful implementation you should also configure your server as a slave for the company's primary DNS server, thereby improving lookup performance for the department's users. The DNS administrator has also decided that server1 should be able to act as a slave for your domain.
Sequence 1: Implement a Minimal DNS Server
Scenario: When faced with a large task, divide it into manageable sequences. Sequence 1 is a simplistic configuration that will start automatically at boot-time and meets all stated access control requirements. It does not make sense to add any real data at this point since the service should be secured before exposing system resources.
Feel free to review the Sequence Solutions if you need help or wish to compare your solution to the suggested method.
Deliverable: A simplistic BIND configuration that listens on the network and meets access
requirements.
System Setup: Enforce selinux protections. This is the first service to be configured on this server, so flush the kernel's firewall rules for a clean start:
service iptables stop
Instructions:
1. Inventory your system and install packages as necessary.
Plan and install packages
You need to install bind and bind-utils to get applications. bind-chroot and caching-nameserver provide an easy starting configuration.
Run rpm -q bind bind-utils bind-chroot caching-nameserver to determine which packages are already installed, if any.
Install needed packages, referring to the Appendix for help.
2. Consider and document which access controls are applicable to your BIND implementation in order to meet the specified requirements.
Complete the access control matrix to be used as an aid while configuring the service:
Check which ports are traditionally used for domain name servers:
grep domain /etc/services
Check whether named is libwrapped. In this case the results indicate that named is not affected by TCP Wrappers.
ldd $(which named) | grep libwrap
strings $(which named) | grep hosts
App-Specific Security
Take a look at /etc/named.caching-nameserver.conf to see the default access control options. Plan to change the listen-on and allow-query directives.
Compare these defaults to the stated requirements, observing that the only missing access directive is for restricting zone transfers. A quick search for "allow" in man 5 named.conf reminds you of the allow-transfer directive. This directive meets the last of the stated access requirements by allowing server1 to slave your zone data.
SELinux
Determine that named is an SELinux-targeted service by checking the policy file:
semanage fcontext -l | grep named
You can check for SELinux booleans by running:
getsebool -a | grep named
If you're unsure about the purpose of these settings, try following up with man pages:
man -k named | grep selinux
The above command should indicate a single man page, named_selinux(8). Perusing this man page reveals that we do not need to modify any SELinux settings. Red Hat provides us with sane defaults!
If the above command fails to indicate a man page, then perhaps you need to run makewhatis &. A pre-configured cron job runs makewhatis every morning at approximately 0402; this job will not have run yet on a fresh build.
3. Create a minimal configuration to meet the access requirements.
Hint: when doing an initial service configuration, it is helpful to perform the following three steps as early in the process as possible:
service <servicename> start
chkconfig <servicename> on
Pre-configuration check
As a precautionary step to avoid confusion, check that the company's DNS administrator has properly delegated name lookups to your station as promised, noting the difference in output from host and dig:
host -rvt ns domainX.example.com
host -rt ns 0.168.192.in-addr.arpa
dig +norecurse -t ns domainX.example.com
dig +norecurse -t ns 0.168.192.in-addr.arpa
Initial configuration and startup
Make sure you have two shells open. In one shell, run:
tail -f /var/log/messages /var/log/audit/audit.log
Keep this shell open; it's useful to follow system messages when restarting a service after each configuration change. Another useful trick is to generate some blank lines by pressing the Enter key a few times in this shell just prior to restarting your service.
Use the second shell to perform the remaining steps.
Determine which directory is installed as the chroot:
cat /etc/sysconfig/named
Copy /etc/named.caching-nameserver.conf as a convenient starting configuration:
cd /var/named/chroot/etc/
cp named.caching-nameserver.conf named.conf
Test whether named will start, looking for errors in /var/log/messages:
service named configtest
service named start
Failure! The log messages should indicate incorrect permissions, so fix these immediately, then test again.
ls -lZ
chown root:named named.conf
chmod 640 named.conf
restorecon named.conf
ls -lZ
service named configtest
service named start
Excellent! Your service started, so take a moment now to ensure it starts at reboot:
chkconfig named on
Implement your access plan
Begin with IPv4 Netfilter rules:
iptables -I INPUT -p tcp --dport 53 -j REJECT
iptables -I INPUT -p udp --dport 53 -j REJECT
iptables -I INPUT 1 -p udp -s 192.168.0.0/24 --dport 53 -j ACCEPT
iptables -I INPUT 1 -p tcp -s 192.168.0.0/24 --dport 53 -j ACCEPT
iptables -I INPUT 1 -p udp -s 127.0.0.1 --dport 53 -j ACCEPT
iptables -I INPUT 1 -p tcp -s 127.0.0.1 --dport 53 -j ACCEPT
service iptables save; restorecon -R /etc/sysconfig
No changes are necessary for TCP Wrappers, Xinetd, or PAM.
Application-specific configuration
One of the first steps to configuring each and every service is to establish the correct interface(s) and port(s) on which the service should listen.
Edit named.conf to change app-specific controls in the global options section:
listen-on port 53 { localhost; 192.168.0.X; };
allow-query { localhost; 192.168.0.0/24; };
allow-transfer { localhost; 192.168.0.254; };
forwarders { 192.168.0.254; };
forward only;
Use the syntax utilities to catch any typing mistakes and restart the service.
service named configtest
service named restart
Confirm that named is listening on the correct interfaces/ports:
netstat -tulpn | grep named
Edit named.conf once again, this time modifying the default view's match-clients statement to read:
match-clients { localhost; 192.168.0.0/24; };
Note that match-clients does the same thing in a view as allow-query does in the global options section. Similarly match-destinations in a view correlates to listen-on in the options.
Use the syntax utilities to catch any typing mistakes and restart the service.
service named configtest
service named restart
4. Change your network configuration to use localhost as your name server.
Configure the local resolver
First, edit /etc/sysconfig/network-scripts/ifcfg-eth0 to prevent dhclient from overwriting the changes you need to make:
PEERDNS=no
Next, edit /etc/resolv.conf to include the following two lines (and only these two lines):
search domainX.example.com
nameserver 127.0.0.1
5. Test!
Test that your changes are effective by restarting named, bouncing the network interface, and performing a query. Watch the messages in your first open shell while restarting named in case there are errors.
service named configtest
service named restart
ifdown eth0; ifup eth0
dig redhat.com | grep SERVER
The previous commands should complete and show your server to be 127.0.0.1 regardless of whether you have Internet access. Note that you did not specify @localhost in your dig since it will look at the nameserver line of /etc/resolv.conf by default.
Follow-Up
At this point, named is configured as a caching-only nameserver without any local data of its own. If you have Internet access, your server should be able to resolve queries for public addresses via recursion through server1. If you do not have Internet access, named will not be able to contact the root servers.
Hint: Now is a great time to make a time-stamped backup copy of your config files!
mkdir ~/backup_configs
TIME=$(date +%Y%m%d%H%M%S)
cp named.conf ~/backup_configs/named.conf.$TIME
cp /etc/resolv.conf ~/backup_configs/resolv.conf.$TIME
cp /etc/sysconfig/iptables ~/backup_configs/iptables.$TIME
Sequence 2: Add Data to the Name Server
Scenario: In sequence 1 you established a minimal configuration that starts automatically at boot-time and employees adequate access controls to avoid exposing corporate data to outside hosts.
In sequence 2 it's time to add some data!
Deliverable: A fully-functional master DNS server for domainX.example.com
Instructions:
1. Add a forward lookup zone for domainX.example.com
Adding zone data requires two major steps:
• Declare a zone in named.conf
• Create a zone file to hold the data
Take stock of what you already have
Conveniently, the caching-nameserver package provides working examples for both steps. Observe that named.conf uses an include statement to read named.rfc1912.zones into its configuration. Look at the included file and review a master zone declaration, such as the one for "localdomain".
grep include named.conf
less named.rfc1912.zones
Notice some things about the declaration for localdomain:
• Each statement ends with a semicolon (;)
• A single statement can be broken into several lines through the use of curly braces
• The zone name is the name of the actual DNS subdomain
• The zone name does not end in a dot
• The name for the zone file is somewhat arbitrary, but in this case is the zone name followed by ".zone" (a reasonable choice)
• The name for the zone file is a relative path; the directory directive in named.conf specifies the directory
Since you installed bind-chroot, the specified directory is also relative to the chroot directory, yielding an absolute path of /var/named/chroot/var/named/localdomain.zone
Declare a forward lookup zone
Edit named.conf and place a similar zone declaration within the statement, preferably directly above the existing include statement. Ensure that your declaration is nested completely within the curly braces that delimit the view:
zone "domainX.example.com" IN {
type master;
file "domainX.example.com.zone";
allow-update { none; };
forwarders {};
};
Take a moment to check the syntax of your changes:
service named configtest
If you made a syntax error, the above command will try to indicate the location of the error.
If your syntax is correct, the above command will list all of the zones your server will be hosting, noting a "file not found" error for domainX.com, since it does not yet have a zone file. This is the expected result and indicates good progress.
Create the zone file
Copy an existing zone file to start your new zone and apply correct permissions:
cd /var/named/chroot/var/named
cp localdomain.zone domainX.example.com.zone
ls -lZ
chown root:named domainX.example.com.zone
chmod 640 !$
ls -lZ
Edit domainX.example.com.zone to convert it to your subdomain:
a. Edit the SOA record...
• Note that the @ sign represents the subdomain and derives its value from the zone declaration in named.conf; this value will be appended to any name in this file that has not been properly terminated with a dot.
• Change localhost to stationX, thereby claiming authority for the subdomain (no trailing dot means the subdomain will be automatically appended).
• Increment the serial number.
b. Change the name server record (NS) to properly indicate your station. The empty column 1 means the record takes that value from the previous record, the SOA in this case.
IN NS stationX
Caution: If an admin puts some other record directly above your NS record, then its meaning could change. Therefore it may be wise to recode the NS record as:
@ IN NS stationX
c. Add an A record for your station:
stationX IN A 192.168.0.X
d. Delete the A record for localhost.
Review your zone file
Look over your new zone file and ask these questions:
• Does your zone file begin with a TTL?
• Do you have an NS record?
• Does the name specified in the NS record have an associated A record?
• Which names are not terminated with a dot and will therefore have the subdomain automatically appended?
If you have followed this solution, then your SOA record still specifies the DNS administrative email data as root with no trailing dot. This means that named will automatically append @, yielding root.domainX.example.com. as the record name and root@domainX.example.com as the effective email.
You could edit root, replacing it with a dot-terminated name. However, you'll be configuring an email server in a subsequent lab, so go ahead and create an MX record now to specify a valid mail server for this domain.
Edit domainX.example.com.zone and add an MX record:
@ IN MX 10 stationX
Note: Many admins expect MX records to follow immediately below NS records. This is not a technical requirement, but it is a good, common practice.
Run the syntax utilities and attempt to restart your service:
service named configtest
service named restart
If named fails to restart after correcting any syntax errors, then review /var/log/messages for errors and try again. Note that you must increment the zone file's serial number after changing zone data.
If named restarts, then this becomes a good time to back up your config files as described earlier.
Finish adding data to your zone file
Edit domainX.example.com.zone to add A records for the remaining stations in your department. Then restart named, remembering to increment the zone's serial number first.
service named configtest
service named restart
2. Test your forward lookups
Make sure that /etc/resolv.conf references your own station as its nameserver and that your station resolves to the correct IP address. The following two commands should return identical results:
dig stationX.domainX.example.com @localhost
dig stationX.domainX.example.com
Make sure that /etc/resolv.conf has the correct search path:
host stationX
Make sure that all stations in your department resolve correctly:
for num in $(seq 1 20); do
host station$num
done
Check your mail exchanger record:
dig -t mx domainX.example.com
Peruse dig's output from the above command to identify several important pieces of information:
• How many ANSWERs were returned?
• How many ADDITIONAL records were returned?
• Which SERVER responded with the answers?
Make sure zone transfers work from your local station, noting that dig's output is in zone file format:
dig -t axfr domainX.example.com
host -l !$
3. Add a reverse lookup zone
Adding a reverse lookup zone is substantially similar to adding a forward zone and requires the same two major steps:
• Declare a zone in named.conf
• Create a zone file to hold the data
Take stock of what you already have
As before, the caching-nameserver package conveniently provides working examples for both steps. Recall that named.conf uses an include statement to read named.rfc1912.zones into its configuration. Look at the included file and review a master zone declaration, such as the one for "0.0.127.in-addr.arpa".
grep include named.conf
less named.rfc1912.zones
Declare your reverse lookup zone
Edit named.conf to add a declaration for your reverse zone, properly nested within your statement:
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.zone";
allow-update { none; };
forwarders {};
};
Again, the zone's filename is somewhat arbitrary, but it should reflect the domain. Having made the change, take a moment to test for typing mistakes.
service named configtest
You should expect to see a file not found error since you have not created the zone file yet. Nevertheless, the lack of syntax errors in named.conf indicates that you're ready to proceed with zone file creation.
Create your reverse zone file
Copy an existing reverse lookup zone and apply correct permissions:
cd /var/named/chroot/var/named
cp named.local 192.168.0.zone
ls -lZ
chown root:named 192.168.0.zone
chmod 640 !$
ls -lZ
Edit 192.168.0.zone to convert it to your domain:
a. Edit the SOA record...
• Again, the @ sign represents the subdomain and derives its value from the declaration in named.conf; this value will be appended to any name in this file that has not been dot-terminated.
• However, observe that each instance of localhost in this zone file is dotterminated, unlike the forward zone file. Why? Imagine what would happen if the responsible party for this domain were root@0.168.192.in-addr.arpa!
With this in mind, consider an appropriate replacement for localhost, such as stationX.domainX.example.com., and make the appropriate changes.
• Increment the serial number.
b. If you have not already done so, change the NS record to properly indicate your station. The empty column 1 means the record takes the value from the previous record, the SOA in this case. To prevent future madness in case somebody re-orders the records, recode the NS record:
@ IN NS stationX.domainX.example.com.
Again, it's absolutely critical to dot-terminate the host name to avoid unpleasantness with name resolution.
After editing the NS record, consider how a client resolves the lookup for this record... the client asks your station for the A record from your forward lookup zone file!
c. Add a PTR record for your station, where X represents your station number:
X IN PTR stationX.domainX.example.com.
d. Delete the existing PTR record for 1 (localhost).
Run the syntax utilities and attempt to restart your service:
service named configtest
service named restart
If named fails to restart after correcting any syntax errors, then review /var/log/messages for errors and try again. Note that you must increment the zone file's serial number after changing zone data.
Finally, add the PTR records to your reverse zone file for the remaining IP's in your subnet (remember to increment the serial number!), then run the syntax utilities and restart your service.
service named configtest
service named restart
If named restarts, then this becomes a good time to back up your config files:
tarfile=~/backup_configs/named-$(date +%Y%m%d%M%H%S).tar
tar cvf $tarfile /var/named/chroot
4. Test your reverse lookups
Test the reverse lookup for your station's IP:
dig -x 192.168.0.X
Peruse dig's output from the above command to identify several important pieces of information:
• How many ANSWERs were returned?
• How many ADDITIONAL records were returned?
• Which SERVER responded with the answers?
Test reverse lookups for the IP's in your department:
for ip in $(seq 1 20); do
host -t ptr 192.168.0.$ip
done
Make sure you can do a zone transfer from your local station, noting that dig's output is in zone file format:
dig -t axfr 0.168.192.in-addr.arpa
host -l !$
Sequence 3: Add Slave DNS Capabilities
Scenario: In this sequence, extend the capabilities of your DNS server to improve lookup performance for your branch office users.
Deliverable: A DNS server that also performs slave duties for the corporate DNS
Lab Setup:
Instructions:
1. Define a slave zone for example.com
Pre-configuration check
To avoid possible confusion while configuring named, first confirm that the remote (master) server will allow us to slave the zone data for example.com:
dig -t axfr example.com @192.168.0.254
host -l example.com 192.168.0.254
Declare the slave zone
Declaring a slave zone is similar to declaring a master zone, but you must provide one additional piece of information: the IP for the master server holding the data. Once again, the name for the zone file is arbitrary, but remember that the default SELinux file contexts allow named to create slave zone files only within the slaves directory.
Edit named.conf to declare your slave zone:
zone "example.com" IN {
type slave;
masters { 192.168.0.254; };
file "slaves/example.com.zone";
forwarders {};
};
Check the syntax of your changes and restart named, watching for errors in /var/log/messages:
service named configtest
service named restart
2. Test the slave transfer
Upon restarting named, you should see a log message stating that a zone transfer has begun, followed a minute or two later by a message stating that the transfer completed successfully.
Check that the file was indeed created:
cd /var/named/chroot/var/named/slaves
ls -lZ
cat example.com.zone
You can also do a non-recursive query to test the zone transfer:
host -r stationX.example.com localhost
dig +norecurse stationX.example.com @localhost
Sequence 4: Cleaning up
Deliverable:
Instructions:
1. Subsequent labs will flow more smoothly if you reset your station so all DNS queries are made from the classroom server. In order to clean up, make sure that you have reset your /etc/resolv.conf, return /etc/hosts to it's original state, and comment out PEERDNS in /etc/sysconfig/network-scripts/ifcfg-eth0.
a. Add these lines to /etc/resolv.conf. You can comment the other lines using a
semi-colon (;).
search example.com
nameserver 192.168.0.254
b. Add these lines to /etc/hosts:
127.0.0.1 localhost.localdomain localhost
192.168.0.X stationX.example.com
c. Comment out the PEERDNS entry in the /etc/sysconfig/network-scripts/ifcfg-eth0 file:
#PEERDNS=no