This chapter described some common DNS problems and how to solve them.
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 files |
or
hosts: nisplus dns files |
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 yet in effect.
Probable cause
The most likely cause is that you forgot to increment the SOA serial number on the master server after you made your change. Since there is no new SOA number, your slave servers do not update their data to match that of the master 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 master data files was set to a value lower than the corresponding serial number on your slave servers. This could happen, for example, if you deleted a file on the master 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 master 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 slave server.
If the SOA serial number in the master file is equal to, or less than, the serial number in the slave file, increase the serial number on the primary's file so that it is greater than the number in the slave 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 slave checks with the primary, it will load the new data. (There are utilities that can force a master to immediately transfer data to the secondaries, if you have one of these utilities you can update the slave 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.
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.
While zone domain-named data is properly transferred from the zone master server to a zone slave server, the reverse domain data is not being transferred. In other words, the host.rev file on the slave is not being properly updated from the primary.
Possible causes
Syntax error in the slave server's boot file.
Diagnosis and Solution
Check the slave server's boot file. Make sure that the master server's IP address is listed for the reverse zone entries just as it is for the hosts data.
When a slave server cannot obtain updates from its master, it logs a master unreachable message. If the problem is not corrected, the slave expires the zone and stops answering requests from clients. When that happens, users start seeing server failed messages.
Symptoms
Masters for slave zone domain unreachable messages in syslog.
*** domain Can't find name: server failed messages to users.
Note that if the problem is with a slave 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 slave's boot file.
Diagnosis and solution
Check that the slave's configuration file contains the correct IP address for the master. Check the line:
zone "someone" { type slave; file "somefile": master [IPaddress; }; }; |
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 slave.
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 192.168.0.1, you would enter the following.
% ping 192.168.0.1 -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.
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 master server's hosts.rev file.
A missing or incorrect delegation of a subdomain 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 192.168.0.1, the doc.com 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.
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.
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 Setting up DNS Servers.