Chapter 14. Troubleshooting DNS and BIND

Contents:

"Of course not," said the Mock Turtle. "Why, if a
fish came to me, and told me he was going on a journey, I should say,
`With what porpoise?'"

"Don't you mean `purpose'?" said Alice.

"I mean what I say," the Mock Turtle replied, in an
offended tone. And the Gryphon added, "Come, let's hear
some of your adventures."

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:

On hosts with vanilla versions of nslookup, you
can often useypmatch 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
useypcat 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: