Troubleshooting

Some basic Solaris utilities can be used to troubleshoot DNS problems. This section shows how to deal with the most common problems.

Error Messages

The first place to look for DNS server error messages is /var/adm/messages . All errors relating to the DNS server are written to this file. The following extract shows that there is a configuration error in /etc/named.conf (normally a bracket or semi- colon has been omitted), and that the expiry time might need to be increased to at least 1 week, because it is currently less:

 Jun  6 18:03:51 ultra10 named[597]: [ID 295310 daemon.error] \ /etc/named.conf:4: syntax error near '}' Jun  6 18:03:51 ultra10 named[597]: [ID 295310 daemon.warning] db.xyz: \ WARNING SOA expire value is less than 7 days (432000) Jun  6 18:03:51 ultra10 named[597]: [ID 295310 daemon.warning] xyz.rev: \ WARNING SOA expire value is less than 7 days (432000) Jun  6 18:03:51 ultra10 named[597]: [ID 295310 daemon.warning] named.local: \ WARNING SOA expire value is less than 7 days (432000) Jun  6 18:03:51 ultra10 named[598]: [ID 295310 daemon.notice] \ Ready to answer queries. 

telnet

You can easily test whether the in.named process is accepting requests by using the telnet command. DNS uses port 53, so connect to this port. If you establish a connection, it is working; if you don't, the process isn't running or there is a problem with it. The following code shows a telnet session to port 53, which connects successfully. Use the Ctrl + ] key to return to the telnet prompt and close to quit.

 ultra5# telnet ultra10 53 Trying 192.168.28.28... Connected to ultra10. Escape character is '^]'. ^] telnet> close Connection to ultra10 closed. 

nslookup

The nslookup command is useful for testing the DNS process. nslookup can be used as a single query command, or interactively where a number of additional functions can be carried out.

It is always a useful test to look up a host that you know is not present in your /etc/inet/ hosts file, but you know exists on the network. The nslookup command returns the resolved information as well as the DNS server used to execute the query, as shown here:

 ultra5# nslookup systemb Server:  ultra10.xyz.com Address:  192.168.28.28 Name:    systemb.xyz.com Address:  192.168.28.127 

You can also test another server, such as a secondary DNS server, by using the nslookup command. The following session output shows the interactive use of nslookup to resolve the same hostname as the preceding example:

 ultra5# nslookup Default Server:  ultra10.xyz.com Address:  192.168.28.28 > server ultra5.xyz.com Default Server:  ultra5.xyz.com.com Address:  192.168.28.29 > systemb Server:  ultra5.xyz.com Address:  192.168.28.29 Name:    systemb.xyz.com Address:  192.168.28.127 > # 

Note that the interactive nslookup facility requires a Ctrl + D keystroke to exit to the command prompt.

Taking a Snapshot of the DNS Database

If there are problems with the DNS server, then taking a snapshot of the DNS database might help to diagnose the cause. You can take a snapshot of the database, which is being cached in the system memory, and write it to an ASCII file for later examination. The snapshot is stored in the file /var/named/named_dump.db and can be useful for finding errors in zone files, for example.

To take a snapshot, enter the following command as root from the command line:

 ultra10# pkill INT in.named 

The action is logged in the /var/adm/messages file as shown here:

 Jun 06 22:44:00 ultra10 named[173]: [ID 295310 daemon.notice] \ dumping nameserver data Jun 06 22:44:00 ultra10 named[173]: [ID 295310 daemon.notice] \ finished dumping nameserver data 

Debugging the in.named Daemon

To debug the in.named process, you can force it to provide a greater amount of output. Debugging is disabled by default, but you can initiate it and increase the debug level incrementally by running the following command a number of times:

 ultra10# pkill -USR1 in.named 

Each time you send in.named the USR1 signal, the debug level is increased, producing more output. Debug output is stored in the file /var/named/named.run .

The following output extract shows the debug output while the nslookup command is being run. It demonstrates how the additional output provides more detailed information about how the resolution process is working:

 ultra10# cat /var/named/named.run Debug level 1 Version = in.named BIND 8.2.4 Sat Apr  6 14:44:58 PST 2002         Generic-5.9-May 2002 conffile = /etc/named.conf Debug level 2 Debug level 3 datagram from [192.168.28.28].32829, fd 23, len 44 req: nlookup(28.28.168.192.in-addr.arpa) id 45076 type=12 class=1 req: found '28.28.168.192.in-addr.arpa' as '28.28.168.192.in-addr.arpa' \ (cname=0) wanted(0xa0318, IN PTR) [IN PTR] wantedtsig(0xa0318, IN PTR) [IN PTR] finddata: added 1 class 1 type 12 RRs req: foundname=1, count=1, founddata=1, cname=0 findns: SOA found req: leaving (28.28.168.192.in-addr.arpa, rcode 0) free_nsp: ultra10.xyz.com rcnt 1 findns: 2 NS's added for '28' free_nsp: ultra10.xyz.com rcnt 1 free_nsp: systemb.xyz.com rcnt 1 doaddinfo() addcount = 3 do additional "ultra10.xyz.com" (from "28.168.192.in-addr.arpa") found it do additional "systemb.xyz.com" (from "28.168.192.in-addr.arpa") found it do additional "28.168.192.in-addr.arpa" (from "28.168.192.in-addr.arpa") found it ns_req: answer -> [192.168.28.28].32829 fd=23 id=45076 size=146 rc=0 datagram from [192.168.28.28].32830, fd 23, len 39 req: nlookup(systemb.xyz.com) id 45077 type=1 class=1 req: found 'systemb.xyz.com' as 'systemb.xyz.com' (cname=0) wanted(0x9e2d4, IN A) [IN A] wantedtsig(0x9e2d4, IN A) [IN A] finddata: added 1 class 1 type 1 RRs req: foundname=1, count=1, founddata=1, cname=0 findns: SOA found req: leaving (systemb.xyz.com, rcode 0) free_nsp: ultra10.xyz.com rcnt 1 findns: 2 NS's added for 'xyz' free_nsp: ultra10.xyz.com rcnt 1 free_nsp: systemb.xyz.com rcnt 1 doaddinfo() addcount = 4 do additional "ultra10.xyz.com" (from "xyz.com") found it do additional "systemb.xyz.com" (from "xyz.com") found it do additional "systemb.xyz.com" (from "systemb.xyz.com") found it do additional "xyz.com" (from "xyz.com") found it ns_req: answer -> [192.168.28.28].32830 fd=23 id=45077 size=122 rc=0 

Notice that the debug level was increased three times; that is, the USR1 signal was sent to the in.named process three times.

To turn off the debugging facility, send the in.named process the -USR2 signal. This sets the debug level to zero, effectively turning the facility off, as shown here:

 ultra10# pkill -USR2 in.named 

A short message is appended to the debug file /var/named/named.run to confirm that debugging has been turned off.

Causing the in.named Daemon to Reread Its Configuration Files

In a similar way to the inetd daemon, you can make in.named reread all its configuration files, without having to stop and start the daemon process itself. The advantage to taking this action is that you don't lose the information held in cache. To make the process reread its configuration files, send in.named the HUP signal, as shown here:

 ultra10# pkill -HUP in.named 

The following information messages are written to the /var/adm/messages file to confirm that the action has been carried out:

 Jun  6 18:06:29 ultra10 named[598]: [ID 295310 daemon.notice] \ reloading nameserver Jun  6 18:06:29 ultra10 named[598]: [ID 295310 daemon.notice] \ Ready to answer queries. 

Using ndc

The ndc utility can be used to monitor and modify the DNS server and provides an alternative to sending various signals to the in.named process. It can be used either directly from the command-line prompt, or interactively. ndc provides much greater control over a DNS server from within a single utility, which enables you to stop and start the server, change or disable the debug levels, and examine the current status, among other things. Run the ndc command and type help to see a list of options. The following session shows an example use of ndc specifying the help and status options:

 ultra10# ndc Type   help  -or-   /h   if you need help. ndc> help (builtin) start - start the server (builtin) restart - stop server if any, start a new one getpid status stop exec reload [zone] ... reconfig [-noexpired] (just sees new/gone zones) dumpdb stats [clear] trace [level] notrace querylog qrylog help quit ndc> status in.named BIND 8.2.4 Sat Apr  6 14:44:58 PST 2002  Generic-5.9-May 2002 config (/etc/named.conf) last loaded at age: Fri Jun  6 18:06:22 2003 number of zones allocated: 64 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF server is up and running ndc> quit 

The status option in this code shows the version of the BIND software in use and that debugging is currently at level 0; that is, debugging is disabled. It also shows that the DNS server is available and running and that there are no queries outstanding.