Network Problems

DNS is wholly dependent on acceptable network conditions. If your network is congested, DNS will be one of the first services to suffer. Most network routers know that the UDP packets DNS uses are disposable, and they are the first to be thrown away, giving TCP traffic priority. Network congestion can be diagnosed by tools such as ping and traceroute, or by suitable network surveillance tools such as MRTG and HP OpenView. If you run a BSD, you can also look at how DNS traffic fares with the nsping tool mentioned in Chapter 7. Another way to see whether DNS traffic suffers is to look at the time information at the bottom of the output from dig:

 ;; Total query time: 136 msec 

A couple of tenths of a second is good. If multiple dig queries result in high query times, your system might be suffering from network problems.

Most IP stacks are tuned for high performance with relatively few large packets. However, DNS uses many small packets. On your DNS server, you might see the data rate flatten out earlier than if it was transferring a file from memory to the network. This is not very likely to happen, though.

Another network problem can be firewalls and packet filters. A common misconception is that DNS uses only UDP port 53, and that TCP is used for only zone transfers. This is wrong. Whenever a DNS query or answer exceeds 512 bytes, TCP is needed. If the query is more than 512 bytes (very unlikely), the querier takes up a TCP connection to the server at once. If the answer is more than 512 bytes, a truncated answer is sent by UDP with the TC (Truncation) bit set. The querier is then meant to connect to the DNS server with TCP and ask the question again, to receive the complete answer. If it can't, the query fails. Although a UDP packet can carry more than 512 bytes over most transmission mediums, RFC 883 specified that a DNS UDP message is restricted to 512 bytes, and to remain compatible, it has stayed so.

You can test whether you can connect to the DNS server you want to test by using telnet. Simply initiate a telnet connection to port 53 on the server; if the connection is opened, you have a clear net all the way to the server. If the connection is refused or times out, the most likely cause is firewalling or packet filtering. Another way is to run dig with the +vc switch. The +vc switch instructs dig to use a virtual circuit, which means it uses TCP. With more sophisticated firewall setups, this might be the only sure way to verify correct operation because it snoops on the protocol to check which kind of protocol it is, and terminates the connection if it is illegal.

You can watch, analyze, and get statistical information about network traffic with programs such as netstat, snooper, tcpdump, trafshow, iptraf, and ethereal. Several of these will take your network traffic to pieces and show you what the bits mean, helping you in a troubleshooting effort.