Testing It All

First, you should make sure that you can see any error messages BIND generates while you work with it. As root, in /etc/syslogd.conf change it to log daemon.info to some file, such as /var/log/named or /var/adm/named if that is the norm in your OS. Remember to HUP your syslogd and then open a window and run tail -f on the log file.

ndc: Starting, Restarting, and Reloading BIND

When, as root, you use the command ndc start, your nameserver will start. Your log window then should display some messages, such as the following (shown here slightly reformatted to fit on this page):

 Mar 28 21:23:58 localhost named[17576]: starting.  named 8.2.2-P5 Sun                 Mar  5 09:57:01 CET 2000                 ^Ijanl@lookfar:/usr/src/bind-8.2.2-P5/src/bin/named Mar 28 21:23:58 localhost named[17576]: hint zone "" (IN) loaded                 (serial 0) Mar 28 21:23:58 localhost named[17576]: master zone                 "0.0.127.in-addr.arpa" (IN) loaded (serial 1) Mar 28 21:23:58 localhost named[17576]: listening on [127.0.0.1].53                 (lo) Mar 28 21:23:58 localhost named[17576]: listening on [192.168.0.2].53                 (eth0) Mar 28 21:23:58 localhost named[17576]: Forwarding source address is                 [0.0.0.0].1039 Mar 28 21:23:58 localhost named[17577]: Ready to answer queries.

Notice in this code that the hint and 0.0.127.in-addr.arpa zones are loaded, and there are no error messages. If something is wrong somewhere, you risk seeing something similar to the following:

 Mar 28 21:18:23 localhost named[17568]: pz/127.0.0:5: SOA for                 "0.0.127.in-addr.arpa.0.0.127.in-addr.arpa" not at                 zone top "0.0.127.in-addr.arpa" Mar 28 21:18:23 localhost named[17568]: Zone "0.0.127.in-addr.arpa"                 (file pz/127.0.0): no NS RRs found at zone top Mar 28 21:18:23 localhost named[17568]: master zone                 "0.0.127.in-addr.arpa" (IN) rejected due to errors 

In the previous code, some typing error caused named to reject the whole 127.0.0 file. The file must be loaded correctly to get the name service working, so if you see any error messages, go back and check the concerned files for typing errors and fix them.

If you see this error

 Mar 28 21:33:58 localhost named[17580]: ctl_server: bind: Address                 already in use 

it means that a nameserver already is running on your machine. Find it and kill it, as long as you're sure it's safe.

ndc is short for Name Daemon Control, and can be used for more than just starting named.ndc help, in combination with the ndc(1) man page, provides complete information. See also Appendix A, "named.conf Man Page."

If you receive error messages when you start named, you should fix them and issue an ndc restart command. If the error occurred in the hint or 127.0.0 zone file, ndc reload is sufficient and will reload the updated zone file(s).

Testing the Zone Files

After the nameserver starts without error messages, it can be tested. I'm going to use dig to test it, so I'll first ask for a record I know it has:

 $ dig @127.0.0.1 1.0.0.127.in-addr.arpa PTR ; <<>> DiG 8.2 <<>> @127.0.0.1 1.0.0.127.in-addr.arpa PTR ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;;      1.0.0.127.in-addr.arpa, type = PTR, class = IN ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa.  1D IN PTR  localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa.   1D IN NS        ns.penguin.bv. ;; Total query time: 51 msec ;; FROM: lookfar to SERVER: 127.0.0.1 ;; WHEN: Tue Mar 28 21:47:37 2000 ;; MSG SIZE  sent: 40  rcvd: 111 

As you see, it returns the PTR record I asked for, and as expected, it points to localhost. If you received a different result, please go back and check the 127.0.0 zone file for typos.

I can ask for one other thing from the 127.0.0 zone file:

 $ dig @127.0.0.1 0.0.127.in-addr.arpa SOA ; <<>> DiG 8.2 <<>> @127.0.0.1 0.0.127.in-addr.arpa SOA ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;;      0.0.127.in-addr.arpa, type = SOA, class = IN ;; ANSWER SECTION: 0.0.127.in-addr.arpa.   1D IN SOA       ns.penguin.bv. hostmaster.penguin.bv. (                                         1               ; serial                                         8H              ; refresh                                         2H              ; retry                                         1W              ; expiry                                         1D )            ; minimum ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa.   1D IN NS        ns.penguin.bv. ;; Total query time: 60 msec ;; FROM: lookfar to SERVER: 127.0.0.1 ;; WHEN: Tue Mar 28 21:55:13 2000 ;; MSG SIZE  sent: 38  rcvd: 112 

Again, the returned data is as expected. If you get something different, go back and check for typos in the zone file.

Now for something more exciting. If you're using a dial-up connection to the Internet, now is the time to get it up and running. To see whether the caching name daemon can resolve names for you, ask it to resolve www.amazon.com:

 $ dig @127.0.0.1 www.amazon.com ; <<>> DiG 8.2 <<>> @127.0.0.1 www.amazon.com ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;;      www.amazon.com, type = A, class = IN ;; ANSWER SECTION: www.amazon.com.         42S IN A        208.216.182.15 ;; AUTHORITY SECTION: www.amazon.com.         1D IN NS        ns-20.amazon.com. www.amazon.com.         1D IN NS        ns-10.amazon.com. ;; ADDITIONAL SECTION: ns-20.amazon.com.       1D IN A         208.33.216.20 ns-10.amazon.com.       1D IN A         208.192.211.10 ;; Total query time: 3743 msec ;; FROM: lookfar to SERVER: 127.0.0.1 ;; WHEN: Tue Mar 28 22:00:28 2000 ;; MSG SIZE  sent: 32  rcvd: 130 

As the previous code shows, the nameserver does its job.

If your nameserver does not return an A record for www.amazon.com, you have some kind of problem you need to find. Are you inside a firewall, for example? If you are, look in named.conf. One solution might be to uncomment the query-source line and restart named. However, if you are inside a firewall, you might not be allowed to access the Internet at all, and this test will fail miserably. Other solutions are using some host outside a firewall to experiment; getting a hole in the firewall for your DNS server; and reading Chapter 3, which discusses forwarding. You might be able to forward DNS queries to a DNS server on the inside of the firewall, which will presumably have Internet access.

The Details of DNS Caching

A caching DNS server is a simple thing to administrate. In addition, it will save you waiting time whenever you try to resolve hostnames because it caches the hostnames you look up for later use. This is especially useful in situations where you're on the wrong end of a slow network link.

A caching DNS server's job is to resolve hostnames. It does so in the manner described in Chapter 1. It saves in its memory pool each and every answer it receives upon sending queries to other DNS servers. The answers stay in the memory pool until they expire. Their expiration time is specified by the TTL of the RR, with each DNS query answer having an associated TTL that tells caching servers how long to cache the answer. If you look at the previous www.amazon.com query answer, the TTL is just 42 seconds. That's hardly any time at all. More typical TTLs are in hours, or perhaps even days, but several Web server addresses have very low TTLs. This enables the Web service administrators to make changes in the service on very short notice because DNS caches won't be out there hanging onto the query answer forever. A low TTL does have one disadvantage, though it can cause an increased load on the network and nameservers. For instance, in the case of www.amazon.com, the record must be re-resolved every 42 seconds. If you have many thousands, or millions, of users, this represents a significant load increase compared to if the TTL was 24 hours.

Some people wonder whether they can control how large the cache will grow, or whether the cache can be saved to disk, enabling it to be persistent across reboots or named restarts. In general, the answer to both these questions is no. However, for more information on controlling how large the cache will grow, see Chapter 8, "Security Concerns."