Troubleshooting

When you start a DNS cache, the /var/log/messages file contains lines similar to the following. Other types of DNS servers display similar messages.

# cat /var/log/messages ... 18:45:18 peach named[10003]: starting BIND 9.3.2 -u named -t /var/named/chroot 18:45:18 peach named[10003]: found 1 CPU, using 1 worker thread 18:45:18 peach named[10003]: loading configuration from '/etc/named.conf' 18:45:18 peach named[10003]: listening on IPv6 interface lo, ::1#53 18:45:18 peach named[10003]: listening on IPv4 interface lo, 127.0.0.1#53 18:45:18 peach named[10003]: command channel listening on 127.0.0.1#953 18:45:18 peach named[10003]: command channel listening on ::1#953 18:45:18 peach named[10003]: zone 0.in-addr.arpa/IN/localhost_resolver: loaded serial 42 18:45:18 peach named[10003]: zone 0.0.127.in-addr.arpa/IN/localhost_resolver: loaded        serial 1997022700 18:45:18 peach named[10003]: zone 255.in-addr.arpa/IN/localhost_resolver: loaded serial 42 18:45:18 peach named[10003]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.        0.0.0.ip6.arpa/IN/localhost_resolver: loaded serial 1997022700 18:45:18 peach named[10003]: zone localdomain/IN/localhost_resolver: loaded serial 42 18:45:18 peach named[10003]: zone localhost/IN/localhost_resolver: loaded serial 42 18:45:18 peach named[10003]: running

With an argument of status, the named init script displays useful information:

# /sbin/service named status number of zones: 6 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/1000 tcp clients: 0/100 server is up and running

When you create or update DNS information, you can use dig or host to test that the server works the way you planned. The most useful part of the output from dig is usually the answer section, which gives the nameserver's reply to your query:

$ dig example.com ... ;; ANSWER SECTION: example.com.            172800  IN      A       192.0.34.166 ...

The preceding output shows that the example.com. domain has a single A record and that record points to 192.0.34.166. The TTL of this record, which tells you how long the record can be held in cache, is 172,800 seconds (2 days). You can also use dig to query other record types by using t option followed by the type of record you want to query for (t works with host, too):

$ dig -t MX redhat.com ... ;; ANSWER SECTION: redhat.com.             600     IN      MX       10 mx1.redhat.com. redhat.com.             600     IN      MX       10 mx3.redhat.com. redhat.com.             600     IN      MX       20 mx2.redhat.com. ...

If you query for a domain that does not exist, dig returns the SOA record for the authority section of the highest-level domain in your query that does exist:

$ dig domaindoesnotexist.info ... ;; AUTHORITY SECTION: info. 7200    IN      SOA     tld1.ultradns.net.domadmin.ultradns.net. ... ...

Because it tells you the last zone that was queried correctly, this information can be useful in tracing faults.

TSIGs

If two servers using TSIGs (page 748) fail to communicate, check that the time is the same on both servers. The TSIG authentication mechanism is dependent on the current time. If the clocks on the two servers are not synchronized, TSIG will fail. Consider setting up NTP (page 1046) on the servers to prevent this problem.