DNS Problems and Solutions

This section describes some common DNS problems and how to solve them.

Clients Can Find Machine by Name but Server Cannot

Symptoms:

DNS clients can find machines by either IP address or by host name, but the server can only find machines by their IP addresses.

Probable cause and solution:

This is most likely caused by omitting DNS from the hosts line of the server's nsswitch.conf file. For example, a bad hosts line might look like this: hosts: files

When using DNS you must include dns in the hosts record of every machine's nsswitch.conf file. For example:

hosts: dns nisplus [NOTFOUND=return] files

or

hosts: nisplus dns [NOTFOUND=return] files

Changes Do Not Take Effect or Are Erratic

Symptom:

You add or delete machines or servers but your changes are not recognized or do not take effect. Or in some instances the changes are recognized and at other times they are not in effect.

Probable cause:

The most likely cause is that you forgot to increment the SOA serial number on the primary master server after you made your change. Since there is no new SOA number, your secondary servers do not update their data to match that of the primary so they are working with the old, unchanged data files.

Another possible cause is that the SOA serial number in one or more of the primary data files was set to a value lower than the corresponding serial number on your secondary servers. This could happen, for example, if you deleted a file on the primary and then recreated it from scratch using an input file of some sort.

A third possible cause is that you forgot to send a HUP signal to the primary server after making changes to the primary's data files.

Diagnosis and solution:

First, check the SOA serial numbers in the data file that you changed and the corresponding file on the secondary server.

• If the SOA serial number in the primary file is equal to, or less than, the serial number in the secondary file, increase the serial number on the primary's file so that it is greater than the number in the secondary file. For example, if the SOA number in both files is 37, change the number in the primary's file to 38. The next time the secondary checks with the primary, it will load the new data. (There are utilities that can force a primary to immediately transfer data to the secondaries, if you have one of these utilities you can update the secondary without waiting for it to check the primary.)

• Review the syslog output for the most recent named nnnn restarted or named nnn reloading nameserver entry. If the timestamp for that entry is before the time you finished making changes to the file, either reboot the server or force it to read the new data as explained in "Forcing in.named to Reload DNS Data".

DNS Client Cannot Lookup "Short" Names

Symptoms:

Client can lookup fully qualified names but not short names.

Possible cause and solution:

Check the client's /etc/resolv.conf file for spaces at the end of the domain name. No spaces or tabs are allowed at the end of the domain name.

Reverse Domain Data Not Correctly Transferred to Secondary

While zone domain-named data is properly transferred from the zone primary master server to a zone secondary server, the reverse domain data is not being transferred. In other words, the host.rev file on the secondary is not being properly updated from the primary.

Possible causes:

Syntax error in the secondary server's boot file.

Diagnosis and Solution:

Check the secondary server's boot file. Make sure that the primary server's IP address is listed for the reverse zone entries just as it is for the hosts data.

For example, the following boot file is incorrect because the primary server's IP address (129.146.168.119) is missing from the secondary in-addr.arpa record:

;
; /etc/named.boot file for dnssecondary
directory /var/named
secondary   doc.com   129.146.168.119        dnshosts.bakup
secondary   168.146.129.in-addr.arpa  doc.rev.bakup

This is what the correct file should look like:

;
; /etc/named.boot file for dnssecondary
directory /var/named
secondary   doc.com   129.146.168.119        dnshosts.bakup
secondary   168.146.129.in-addr.arpa   129.146.168.119  doc.rev.bakup

Server Failed and Zone Expired Problems

When a secondary server cannot obtain updates from its master, it logs a master unreachable message. If the problem is not corrected, the secondary expires the zone and stops answering requests from clients. When that happens, users start seeing server failed messages.

Symptoms:

• Masters for secondary zone domain unreachable messages in syslog.

• Secondary zone domain expired messages in syslog.

• *** domain Can't find name: server failed messages to users.

Note that if the problem lies with a secondary server, some users could still be successfully obtaining DNS information from the master and thus operating without experiencing any difficulty.

Possible causes:

The two most likely causes for these problems are network failure and a wrong IP address for the master in the secondary's boot file.

Diagnosis and solution:

• Check that the secondary's boot file contains the correct IP address for the master. Check the line:

  secondary domain IPaddress hostsfile

Make sure that the IP address of the master matches the master's actual IP address and the address for the master specified in the hosts file. If the IP address is wrong, correct it, and then reboot the secondary.

• If the master's IP address is correct, make sure the master is up and running correctly by pinging the master's IP address: For example, to ping the master at IP address 129.146.168.119, you would enter:

% ping 129.146.168.119 -n 10

• If the master does not respond to the ping, make sure it is up and running properly.

• If the master is running okay, use ps to make sure it is running named. If it is not running named, reboot it.

• If the master is correctly running named, you most likely have a network problem.

rlogin, rsh, and ftp Problems

Symptoms:

• Users are asked for password when they try to rlogin to a machine in another domain over the Internet.

• Users are denied access when they try to ftp to a machine in another domain over the Internet.

• Users are denied access when they try to use rlogin or rsh to a machine on their own network.

Possible causes:

• The user is working at a machine that does not have a PTR record in the primary master server's hosts.rev file.

• A missing or incorrect delegation of a sub-domain in the hosts.rev file.

Diagnosis and solution:

Check the appropriate hosts.rev file and make sure there is a PTR record for the user's machine. For example, if the user is working at the machine altair.doc.com with an IP address of 129.146.168.46, the doc.com primary master server's doc.rev file should have an entry like:

46 	IN	 PTR 	altair.doc.com.

If the record is missing, add it to the hosts.rev file and then reboot the server or reload its data as explained in "Forcing in.named to Reload DNS Data".

Check and correct the NS entries in the hosts.rev files and then reboot the server or reload its data as explained in "Forcing in.named to Reload DNS Data".

Other DNS Syntax Errors

Symptoms:

Error messages in console or syslog with operative phrases like the following are most often caused by syntax errors in DNS data and boot files:

• No such...

• Unknown field...

• Non-authoritative answer:

• Database format error...

• illegal or (illegal)

• error receiving zone transfer

Check the relevant files for spelling and syntax errors.

A common syntax error is misuse of the trailing dot in domain names (either using the dot when you should not, or not using it when you should). See "Trailing Dots in Domain Names".