Chapter 14. Troubleshooting DNS and BIND
"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?'"
Contents:Is NIS Really Your Problem?
Troubleshooting Tools and Techniques
Potential Problem List
Interoperability and Version Problems
"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 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:% nslookup Default NIS Server: terminator.movie.edu Address: 126.96.36.199 >
Whereas in this example, the answer came from a name server:% ypmatch ruby hosts 188.8.131.52 ruby ruby.ora.com %
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.% ypmatch harvard.harvard.edu hosts 184.108.40.206 harvard.harvard.edu %
If you find the answer in NIS (and you know NIS is being consulted first), you've found the cause of the problem.% ypcat hosts | grep andrew.cmu.edu
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:
while this entry has the name resolver querying DNS first:hosts: nis dns files
For more detailed information on the syntax and semantics of the nsswitch.conf file, see Chapter 6, "Configuring Hosts".hosts: dns nis files
Copyright © 2002 O'Reilly & Associates. All rights reserved.