Chapter 14. Troubleshooting DNS and BIND

In the last two chapters, we've demonstrated how to use nslookup and dig, and how to read the name server's debugging information. In this chapter, we'll show you how to use these tools -- plus traditional Unix networking tools like trusty ol' ping -- to troubleshoot real-life problems with DNS and BIND.

Troubleshooting, by its nature, is a tough subject to teach. You start with any of a world of symptoms and try to work your way back to the cause. We can't cover the whole gamut of problems you may encounter on the Internet, but we will certainly do our best to show how to diagnose the most common of them. And along the way, we hope to teach you troubleshooting techniques that will be valuable in tracking down more obscure problems that we don't document.

14.1. Is NIS Really Your Problem?

Before we launch into a discussion of how to troubleshoot a DNS or BIND problem, we should make sure you know how to tell whether a problem is caused by DNS as opposed to NIS. On hosts running NIS, figuring out whether the culprit is DNS or NIS can be difficult. The stock BSD nslookup, for example, doesn't pay any attention to NIS. You can run nslookup on a Sun and query the name server 'til the cows come home while all the other services are using NIS.

How do you know where to put the blame? Some vendors have modified nslookup to use NIS for name service if NIS is configured. The HP-UX nslookup, for example, will report that it's querying an NIS server when it starts up:

% nslookup
Default NIS Server:  terminator.movie.edu
Address:  192.249.249.3

>

On hosts with vanilla versions of nslookup, you can often use ypmatch to determine whether you're using DNS or NIS. ypmatch prints a blank line after the host information if it received the data from a name server. So in this example, the answer came from NIS:

% ypmatch ruby hosts
140.186.65.25   ruby ruby.ora.com
%

Whereas in this example, the answer came from a name server:

% ypmatch harvard.harvard.edu hosts
128.103.1.1     harvard.harvard.edu

%

Note that this works with SunOS 4.1.1, but is not guaranteed to work on all future versions of SunOS. For all we know, this is a bug-cum-feature that may disappear in the next release.

A more surefire way to decide whether an answer came from NIS is to use ypcat to list the hosts database. For example, to find out whether andrew.cmu.edu is in your NIS hosts map, you could execute:

% ypcat hosts | grep andrew.cmu.edu

If you find the answer in NIS (and you know NIS is being consulted first), you've found the cause of the problem.

Finally, in the versions of Unix that use the nsswitch.conf file, you can determine the order in which the different name services are used by referring to the entry for the hosts database in the file. An entry like this, for example, indicates that NIS is being checked first:

hosts:    nis dns files

while this entry has the name resolver querying DNS first:

hosts:    dns nis files

For more detailed information on the syntax and semantics of the nsswitch.conf file, see Chapter 6, "Configuring Hosts".

These hints should help you identify the guilty party or at least exonerate one suspect. If you narrow down the suspects and DNS is still implicated, you'll just have to read this chapter.

Chapter 14. Troubleshooting DNS and BIND

Contents:

14.1. Is NIS Really Your Problem?