Troubleshooting DNS

Many DNS troubleshooting techniques were discussed previously in this chapter, such as using the telnet program to detect reverse-DNS problems. Other troubleshooting options include script programs and named logging options.

Using Scripting to Stress-Test Your DNS Setup

You can make two handy scripts to stress-test your DNS setup. They can be named anything, but this example calls them check1and check. The check1 script simply records the results of an nslookup in file junk.jnk, while check calls check1 for each domain and IP under consideration. Here’s the code for check1:

echo "nslookup $1 $2" >> junk.jnk
nslookup $1 $2 >> junk.jnk
echo " " >> junk.jnk
echo " " >> junk.jnk

check1 simply writes the nslookup of its arguments to a file. check takes a single argument that, if present, it passes as arg2 to various check1 calls. Here’s the code for check:

rm junk.jnk
./check1 mainserv $1
./check1 mydesk $1
./check1 mainserv.domain.cxm $1
./check1 mydesk.domain.cxm $1
./check1 www.domain.cxm $1
./check1 192.168.100.1 $1
./check1 192.168.100.2 $1
less junk.jnk

The preceding script should run quickly and produce the right output. If not, there is a problem. By selectively commenting out lines of the check script, you can narrow down the scope of the problem.

The nslookup program delivers many powerful features when used interactively. It can also lead to frustrating hangs. For enhanced troubleshooting, learn about nslookup from its man page.

Debugging with Dumps and Logs

One of the main debugging tools you have with named is having the daemon dump its cached database to a text file. To have nameddump its cache, you must send the daemon an INT signal. The file /var/run/named.pid contains the process ID of named. The following command sends the INT signal to named:

   # kill –INT  `cat /var/run/named.pid`

The file /var/named/named_dump.db will contain the cache information that was dumped. The cache file will look similar to a zone database file.

The named daemon also supports debug logging. To start the daemon logging, send the daemon a USR1 signal like this:

   # kill –USR1  `cat /var/run/named.pid`

The logging information is logged in the /var/named/named.run file. If the USR1 signal is sent to the daemon, the verbosity of the logging information increases. In fact, it’s so verbose that you’ll need to search for strings like error and not found. To reset the debug level to 0, send the daemon a USR2 signal.

The HUP signal can be sent to the named daemon each time a zone database is changed, and theoretically the HUP signal rereads the databases without having to kill and restart the named daemon. But in fact, sometimes the HUP signal doesn’t always work as advertised. The following example sends the HUP signal to named:

   # kill –HUP  `cat /var/run/named.pid`

Another great debugging technique, especially after you’ve restarted named, is to look at the system log. You can find what file contains the appropriate log by looking in /etc/syslog.conf. Default for Red Hat 7 is /var/log/messages. Because you’re interested only in recent messages, grab the tail end of the file with this command:

   # tail -n 400 /var/log/messages | less -N

All log entries have date and time, so if need be you can read back more than 400 lines. Look especially for error, not found, no such, fail, and so on. Carefully evaluate any error messages and try to figure out what they mean and what caused them.

Checking Your DNS Configuration with dnswalk

I find dnswalk an indispensable tool. It checks your DNS configuration very thoroughly. It’s the DNS equivalent of C’s lint utility or Samba’s testparm utility. Using dnswalk first can easily save hours of troubleshooting, so it’s worth the few minutes it takes to install and use it.

The dnswalk utility depends on the perl-Net-DNS tool, so the latter must be installed first. When using the Red Hat distribution, the easiest installation is via rpm. First, obtain these two files from the net:

ftp://rufus.w3.org/linux/contrib/libc5/i386/perl-Net-DNS-0.12-1.i386.rpm

ftp://rufus.w3.org/linux/contrib/noarch/noarch/dnswalk-2.0.2-1.noarch.rpm

Now install them with the following two commands:

   # rpm -ivh perl-Net-DNS-0.12-1.i386.rpm


   # rpm -ivh dnswalk-2.0.2-1.noarch.rpm

It’s essential to install them in the preceding order, because dnswalk depends on perl-Net-DNS. The dnswalk executable, which is really a Perl program, is installed in /usr/sbin directory. dnswalk is used by naming a domain as the sole argument. The domain must end in a dot (.). The following is an example:

   # dnswalk domain.cxm.
Checking domain.cxm.
BAD: domain.cxm. has only one authoritative nameserver
Getting zone transfer of domain.cxm. from mainserv.domain.cxm...done.
SOA=mainserv.domain.cxm contact=hostmaster.domain.cxm
0 failures, 0 warnings, 1 errors.
#

You’ll note that the only error it finds is the lack of a secondary DNS server. Most examples in this chapter define only one DNS server. In the following example, named.domain.cxm has been changed so that mydesk.domain.cxm resolves to192.168.100.22, but the reverse lookup in named.192.168.100 is left at 192.168.100.2. This is a forward/reverse mismatch—a serious problem that would have been very difficult to diagnose with tools like nslookup:

   # dnswalk domain.cxm.
Checking domain.cxm.
BAD: domain.cxm. has only one authoritative nameserver
Getting zone transfer of domain.cxm. from mainserv.domain.cxm...done.
SOA=mainserv.domain.cxm contact=hostmaster.domain.cxm
WARN: mydesk.domain.cxm A 192.168.100.22: no PTR record
0 failures, 1 warnings, 1 errors.
#

In the preceding code, note the “no PTR record” warning, indicating that there’s no reverse DNS for 192.168.100.22.

If you configure DNS on anything more than the most casual basis, dnswalk is a vital investment. Use it early and often.

 

source: http://www.informit.com/library/content.aspx?b=red_hat_linux7&seqNum=132