Debian Clusters for Education and Research: The Missing Manual

Testing and Troubleshooting BIND

From Debian Clusters

Jump to: navigation, search

This is the last page of a five part tutorial on setting up Name Service: DNS and BIND. The full tutorial includes

Bind Won't Restart

I've only see this happen once. Bind was just installed in the usual manner but wouldn't restart. I was using rncd reload, which just tells the daemon to reload the configuration files.

metaserver:/etc/bind# rndc reload
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not syncronized, or
* the key is invalid.

This happened many times, even after uninstalling and reinstalling Bind. Eventually I just restarted the machine, and after that, it worked fine. I'm not sure what caused it, but rebooting the machine solved the problem.

/var/log/syslog Errors

Bind should have just been restarted with /etc/init.d/bind9 restart. The next step is to check /var/log/syslog for errors that Bind will continue in the presence of. Below are a few easy slip ups that can stop the set up from functioning correctly. After making any changes, be sure to restart Bind again.

Missing Period in a Zone File

There are lots of shortcuts I didn't have the space to cover earlier. One of these is that any IP address on the right side of a line or any full domain name that doesn't end with a period has the zone added to it. Below is what happens when using "192.168.1.254" instead of "192.168.1.254." in part of the nameserver declaration. Because the first one doesn't have a period at the end, the zone raptor.loc is appended to it, which can't resolve correctly.

Jul  3 19:43:18 eyrie named[2961]: zone raptor.loc/IN: NS '192.168.1.254.raptor.loc' has no address records (A or AAAA)

Filename Typo

The names of the zone files you create in /etc/bind need to match those you specified in /etc/bind/named.conf.local. If they don't, you'll get an error like this.

Jul  3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file
  /etc/bind/db.1.169.192 failed: file not found

Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS?

This one's a little more cryptic than the other errors.

Jul  3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:3: ignoring out-of-zone data (raptor.loc)
Jul  3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:12: ignoring out-of-zone data (raptor.loc)
Jul  3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has 0 SOA records
Jul  3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has no NS records

The clue comes in with the two different zones mentioned in the error - 1.168.192 and raptor.loc. Neither one should know anything about the other. If one references the other, it's probably because the important parts (the domain name specification) weren't specified after copying the forward DNS records to the reverse DNS records. Oops!

Turning Logging On/Off

For hunting down some of the problems when turning DNS loose for the first time, it's often handy to have logging turned on. To have DNS log all queries to /var/log/syslog, use

rndc querylog

Having querylog on will result in lines like the following being written. To turn it off, issue the same command again.

Jul  3 21:25:40 eyrie named[3189]: client 192.168.1.200#32793: query: eyrie.raptor.loc IN A +
Jul  3 21:25:41 eyrie named[3189]: client 192.168.1.200#32793: query: gyrfalcon.raptor.loc IN A +

Testing

All right, finally time to test it out! The easiest way to test out Bind is with the host command, followed by an IP address or name. Using an IP tests out reverse DNS, while using a name tests out forward DNS. It's a good habit to test it out on both the server and one of the clients as well. Below are a few common problem areas.

Record not found, server failure

eyrie:~# host eyrie
eyrie A record not found, server failure

This indicates that the correct nameserver isn't being used. For machines with static IPs, this means lines needed to be added to /etc/resolv.conf to tell it to query the right nameserver. Adding these next two lines does the trick. The first tells it to append your domain name to partial queries (in my case, so querying for harrier becomes a query for harrier.raptor.loc), and the second tells it to ask the proper nameserver. This should go before any other lines in your file.

search <your domain>
nameserver <nameserver IP>

For dynamic IPs, the domain and the nameserver IP address need to be specified in /etc/dhcp3/dhcpd.conf options on the DHCP server.

Does not exist, try again

eyrie:~# host eyrie
eyrie does not exist, try again

This is part of the same problem as above, specific to the search <your domain> line in /etc/resolv.conf. Edit that file manually for machines with static IP addresses, or see DHCP Server to change it for machines being handed IPs dynamically.

eyrie:~# host eyrie
eyrie.raptor.loc does not exist, try again

Other half of the same problem from above. This time, since search has been specified, the domain is appended as it should be, but the correct nameserver isn't being contacted.

Record query refused

eyrie:~# host eyrie
eyrie.raptor.loc A record query refused

After getting this error, you'll see an entry in /var/log/syslog:

eyrie:~# tail /var/log/daemon.log
Jul  3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied

This indicates a problem with an allow-query { } option in /etc/bind/named.conf.options. The field can take arguments in various forms, including IP addresses and CIDR masks. (See man named.conf for options.) These need to be separated with semi-colons and the list ended with a semi-colon as well.

Does not exist (Authoritative answer)

gyrfalcon:~# host eyrie
eyrie.raptor.loc does not exist (Authoritative answer)

At least it's sure about it! Actually the authoritative answer bit means that the correct nameserver is being asked, which means that the correct nameserver is being asked. Asking for a hostname and receiving this answer indicates a problem with forward DNS; asking for an IP and receiving it means a problem with reverse DNS. If the zone file is set up correctly, the serial number has been incremented when making changes, and Bind has been restarted after any changes, then this might be a missing period issue in the forward/reverse DNS file. If you can do something crazy like this

eyrie:/etc/bind# host gyrfalcon.raptor.loc.raptor.loc
gyrfalcon.raptor.loc.raptor.loc A       192.168.1.200

then it's definitely a missing period in /etc/bind/db.yourdomain (for forward DNS) or db.yourIPreversed (for reverse DNS).

Success!

kwanous@gyrfalcon:~$ host peregrine
peregrine.raptor.loc    A       192.168.1.205

kwanous@gyrfalcon:~$ host 192.168.1.205
Name: peregrine.raptor.loc
Address: 192.168.1.205
Personal tools