42.3. DNS (Topic 2.207) 42.3.1. Review Questions You wish to use the dig command to query the server named dns1.company.com to see whether the PTR record for the system named adam exists. What would this command look like? Consider the following text: zone "." { type hint; file "/etc/bind/db.root"; };
What is the purpose of this entry, and what file does this entry belong in? You have been given a new host to enter into the forward DNS zone. This hostname is for the Web server. The host's IP address is 192.168.2.5, and the host's name is www.company.com. Write in the entry you would create in the DNS server's forward zone file for this server. You wish to establish a chroot jail for your DNS server. You are using BIND. Why is it necessary to copy or move directories such as the /etc/bind directory to another, special location on the hard drive? Your system ships with the BIND 8 dnskeygen command, rather than the BIND 9 dnssec-keygen command. Both have the same function. Using dnskeygen or its equivalent, what command would you issue to create a public-key pair with the size of 1024 bits that can be used only for authentication for the mycompany.com domain? You are in an interactive nslookup session. What command would you issue to switch from the default nameserver to dns2.company.com?
42.3.2. Answers Enter: # dig @dns1.company.com PTR adam
The text primes the DNS server to look for root servers. This entry belongs in the named.conf file. Create the following entry in the DNS server's forward zone file: IN A www 192.168.2.5
The purpose is to provide BIND with an isolated environment. If a buffer overflow or other problem occurs, any exploit or other problem will remain local to that environment and will not be able to spread easily to the rest of the system. The command is: # dnskeygen -H 1024 -c -h key.mycompany.com.
The command is: > server dns2.company.com
42.3.3. Exercises Install BIND on your system. Take some time to verify where the configuration files are. In many newer systems, the files will be located in the /etc/bind directory. In other systems, the files will be located in both the /etc directory and in the /var/named subdirectories. Once you have confirmed the location of these files, verify the location of the startup script. In some systems, it will be in the /etc/rc.d/init.d directory. In other systems, it will be in the /etc/bind directory. Sometimes, the startup file is called named. In other cases, it is called bind9. The names and locations of files may vary. This series of exercises will assume that all configuration files reside off of the /etc/bind directory. Using sample zone files that reside on the local system or on the Internet, review the syntax of valid DNS entries. Also review the syntax for the named.conf file, the top-level nameserver file, and the forward and reverse loopback zone files. Configure BIND to act as a DNS server for your network. First, configure the /etc/bind/named.conf file so that it contains references for the root servers, and so that this server knows that it is authoritative for the zone you are going to create. You will also need to add forward and reverse loopback zones, as well as references for the forward and reverse zones you are going to create. Remember the names and locations of the forward and reverse zone files. You will be creating these files in the next step. As you configure named.conf, make sure that you are referencing all files properly and that these files exist, even if they are currently empty. Use the touch command to create the files, or download sample files from the Internet. The files for the forward and reverse loopback zones should already exist on your system. If your system has not already provided them, obtain hint files from http://www.bind.org. Using a text editor, create both forward and reverse lookup zone files in the /etc/bind directory. Make sure that these files have the same names as those indicated in the /etc/bind/named.conf file. Populate the forward and reverse zone files with valid entries. The entries you create will include valid TTL and SOA information, valid nameserver information, and A records. Make sure as you start BIND that you review the /var/log/messages file. Using the tail -f command is a good idea, as it will help you read any error messages BIND gives. You may also have to verify that the BIND service is running. One way to do this is to use the ps aux command and pipe the output through grep: ps aux | grep bind
You will likely have to make several changes to the forward and reverse zone files before BIND properly initializes and begins resolving names. You will have to restart your server whenever you make a change to your zone or configuration files. Once you have started BIND, configure the /etc/resolv.conf file for your DNS server and also for your clients so that they are using your DNS server. Use the ping command to verify that you can access hosts by both IP address and by DNS hostname. Use nslookup in interactive mode, as well as a one-time command, to verify that your server is properly resolving names. In some systems, nslookup is deprecated. You can use the -sil option to eliminate the warning messages. While using nslookup, change between DNS servers, view A and PTR records, review the SOA record for the zone, and see if you can conduct a zone transfer. The dig command is quite sophisticated. Use the dig command to query your forward and reverse zone records, as well as review the SOA fields. You can also use BIND to query other DNS servers and conduct zone transfers if the DNS server allows such activity (increasingly unlikely). Make sure that you know the options that allow you to conduct multiple inquiries. The host command is quite handy for conducting quick DNS searches. Make sure that you know the options that allow you to conduct zone transfers and specify the types of records you wish to view (e.g., SOA, CNAME, and AXFR). You already have a working server. However, you can add more names. Add CNAME and MX records to your zones. When you make changes, make sure that you increment the serial number so that changes are recognized by secondary (i.e., slave) DNS servers. Configure a secondary (slave) DNS server. Conduct zone transfers to verify that your configuration has worked. Once you are confident that your master/primary and secondary/slave DNS servers are working properly, secure them. Use the dnskeygen command (or its equivalent) to create public keys for your zones. Then take the necessary steps to require authentication and encryption for all zone transfers. Then configure named.conf to restrict zone transfers to certain servers. Even though such settings can be rather easily fooled by attackers who know how to spoof IP addresses, you may as well lock down as many settings as possible. Also consider stopping all other daemons and dedicating this system to just providing name resolution. Even if you are simply experimenting, consider the daemons that you would shut down if you were to configure this system as a dedicated DNS server.
|
