Troubleshooting DNS


Several sources offer good information about finding and fixing DNS errors. The DNSRD Tricks and Tips page at http://www.dns.net/dnsrd/trick.html and the comp.protocols.tcp-ip.domains FAQ (an HTML version is located at http://www.intac.com/~cdp/cptd-faq/) are good places to start. This section discusses some of the more common errors and their cures.

Note

RFC 1912, "Common DNS Operational and Configuration Errors," discusses several of the most common DNS problems at length. It is available at http://www.intac.com/~cdp/cptd-faq/.


Delegation Problems

Your zone must be delegated to the nameservers authoritative for them, either by the root nameservers or the parents of the zone in question. Improper delegation can cause the name service for your domain to become dysfunctional, prevent some networks from using the name service, and numerous other problems. These problems typically occur only in the initial stages of setting up a domain when the delegations have not propagated widely yet.

If you experience such problems, you can use dig to follow delegation chains and find the point at which problems occur. A tool such as dnswalk might also be useful (see "Tools for Troubleshooting," later in this chapter).

Lame delegation is another common DNS delegation problem. Lame delegation occurs when a nameserver is listed as being authoritative for a zone, but in fact is not authoritative (it has not been configured to be a master for the zone); the nameserver in a lame delegation is called a lame server. Unfortunately, lame delegations are very common on the Internet. They can be the temporary result of domains being moved or (especially in the case of reverse zones) more permanent configuration errors that are never detected because of a lack of attention to detail.

If your registrar's bills for your domain are not promptly paid, the registrar might discontinue the delegation of authority for your zone. If this happens (and the whois record for your domain usually mentions this), the best thing to do is quickly pay the registrar and ask for a renewal of the delegation. It is better not to let it happen, though, because such changes can take a relatively long time to make and propagate.

Reverse Lookup Problems

Reverse lookup problems are often very hard to diagnose because they manifest themselves as failures in systems other than DNS. Many security-sensitive services perform reverse lookups on the originating host for all incoming connections and deny the connection if the query fails.

Even if reverse resolution succeeds, many servers might reject connections from your host if your A and PTR records do not match. That is, the PTR record for a particular IP address refers to a name and the A record for that name refers to a different IP address. They perform a double lookup to verify that the PTR and A records match to eliminate spoofing attacks. Carefully maintain your reverse zones at all times.

Delegation problems are a frequent source of woe. Unfortunately, many ISPs appear unable to understand, configure, or delegate reverse zones. In such cases, you often have little choice but to try and tell your ISP what to do to fix the problem. If the ISP staff refuses to listen, find a new ISP (or live with broken DNS).

Another typical symptom of failing reverse lookups is an abnormally long delay on connection attempts. This happens when the server's query for a PTR record is not answered and times out (often because of network problems or the nameserver being down). This can be baffling to diagnose, but you should suspect DNS problems whenever you hear questions such as "Hey! Why is my web browser taking so long to connect?"

Maintaining Accurate Serial Numbers

Accurate serial numbers are very important to the correct operation of slave servers. An increase in the serial number of a zone causes slaves to reload the zone and update their local cache.

A common mistake that system administrators make is forgetting to increment the serial number after a change to the zone data. If you make this mistake, secondary nameservers won't reload the zone, and continue to serve old data. If you suspect that the data on the master and slave servers is out of sync, you can use dig to view the SOA record for the zone on each server (dig @master domain SOA and dig @slave domain SOA) and compare the serial numbers in the responses.

Another common problem is setting the serial number to an incorrect valueeither too small or too large. A too-small serial number causes slaves to think that they possess a more up-to-date copy of the zone data, but this is easily corrected by increasing the serial number as necessary. A too-large serial number is more problematic and requires more elaborate measures to repair.

Serial number comparisons are defined in such a way that if a serial numberwhen subtracted from another with no overflow correctionresults in a positive number, the second number is newer than the first, and a zone transfer is required. (See RFC 1982 "Serial Number Arithmetic" for details.) You can exploit this property by temporarily setting the serial number to 232 (4,294,967,296), waiting for all the slaves to reload the zone, and then setting it to the correct number.

Troubleshooting Problems in Zone Files

The most common error in zone data is to forget that names in a zone file are relative to the origin of the zone, not to the root. Writing www.example.com in the zone file for example.com and expecting it to be fully qualified causes names such as www.example.com.example.com to show up in the DNS. You should either write www, which is qualified to the correct www.example.com, or write www.example.com. (with the trailing period) to indicate that the name is fully qualified.

The SOA record should contain (as the first field) the domain name of the master server (not a CNAME) and a contact address (with the @ replaced by a ".") to report problems to. Mail sent to this address should be read frequently. The other fields should contain sensible values for your zone, and the serial number should be correctly incremented after each change.

As discussed earlier, A and PTR records should always match; that is, the A record pointed to by a PTR record should point back to the address of the PTR record. Remember to quote the two arguments of HINFO records if they contain any whitespace. Avoid the use of CNAME records for MX, NS, and SOA records.

In general, after making changes to zone data, it is a good idea to reload named and examine the logs for any errors that cause named to complain or reject the zone. Even better, you could use one of the verification tools, such as dnswalk, discussed briefly next.

Tools for Troubleshooting

BIND includes the always useful dig program, as well as named-checkconf (to check /etc/named.conf for syntax errors) and named-checkzone (to do the same for zone files). We also especially recommend dnswalk and nslint. dnswalk is a Perl script that scans the DNS setup of a given domain for problems. It should be used in conjunction with RFC 1912, which explains most of the problems it detects. nslint, like the analogous lint utility for C programs, searches for common BIND and zone file configuration errors.

By occasionally using these programs to troubleshoot DNS problems (especially after nontrivial zone changes), you go far toward keeping your DNS configuration healthy and trouble free.

Using Fedora's BIND Configuration Tool

Fedora provides a dozen or more different graphical configuration tools system administrators can use to configure network (and system) services. One of these tools is system-config-bind, a deceptively simple BIND configuration tool that requires an active X session and must be run with root privileges.

You can launch this client by using the command system-config-bind from a terminal window or by selecting the Domain Name Service menu item from the Server Settings menu. system-config-bind is automatically installed if you select the Fedora configuration tools.

Note

Using system-config-bind and then saving any changes overwrites existing settings! If you prefer to manually edit your named configuration files, do not use system-config-bind. Always make a backup of the configuration files in any eventyou'll be glad you did.


After you type the root password and press the Enter key, the client launches. You then see its main window, as shown in Figure 27.2.

Figure 27.2. Fedora's system-config-bind utility can be used to create, modify, and save basic domain nameserver settings.


system-config-bind can be used to add a forward master zone, reverse master zone, MX records, or slave zone. Click the Add Record button to select an entry for configuration, as shown in Figure 27.3.

Figure 27.3. Use system-config-bind to add a new DNS record to your server or edit the existing settings.


Existing settings can be edited or deleted by first selecting and then clicking the Edit or Delete button in the system-config-bind dialog. When you finish entering or editing your custom settings, select the Apply menu item from the File menu. Configuration files are saved in /etc/named.conf and under the /var/named directory.



Red Hat Fedora 5 Unleashed
Red Hat Fedora 5 Unleashed
ISBN: 067232847X
EAN: 2147483647
Year: 2004
Pages: 362

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net