Recipe 24.22. Testing and Querying DNS Servers with dig and dnstrace

24.22.1 Problem

You want a utility for querying DNS servers; you want to be able to query specific servers for different record types, or make general queries that report all data for a domain. You are especially interested in what your servers are reporting to the world. You also want to trace all the upstream servers that affect the resolution of your domain name. And you are nosy about other people's networks.

24.22.2 Solution

dig, the Domain Information Groper, can do pretty much any kind of DNS query you want. dnstrace is the best tool for tracking down possible upstream troubles, such as misconfigured DNS servers that report your domain information incorrectly.

This is probably the most common dig query; it retrieves the complete resource record for a domain from the name servers specified in your resolv.conf file:

$ dig debian.org

; <<>> DiG 9.2.4rc5 <<>> debian.org

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43802

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

   

;; QUESTION SECTION:

;debian.org.                    IN      A

   

;; ANSWER SECTION:

debian.org.             3600    IN      A       192.25.206.10

   

;; AUTHORITY SECTION:

debian.org.        3600    IN      NS      saens.debian.org.

debian.org.        3600    IN      NS      spohr.debian.org.

debian.org.        3600    IN      NS      klecker.debian.org.

debian.org.        3600    IN      NS      newsamosa.debian.org.

   

;; ADDITIONAL SECTION:

newsamosa.debian.org.   3600    IN      A       208.185.25.35

   

;; Query time: 383 msec

;; SERVER: 12.169.174.2#53(12.169.174.2)

;; WHEN: Tue Aug 24 15:36:36 2004

;; MSG SIZE  rcvd: 146

It shows you three things:

The QUESTION SECTION shows your inquiry.
The ANSWER SECTION is your answer.
The AUTHORITY SECTION lists the authoritative server(s) for the domain.

You can query the authoritative server for a domain directly. For example, to query your own authoritative server, you'd use:

$ dig @ns.pixels.net.  pixels.net

You can also specify a particular record type (any, a, ns, mx, ptr, txt, cname, soa, hinfo, rp, sig, key, aaaa, or axfr) like this:

$ dig cname @ns.pixels.net. pixels.net

dnstrace, which comes with djbdns, searches for all DNS servers that can affect the resolution of your selected domain name, starting from the specified root server. This can take a long time to run and may produce a lot of output, so the best thing to do is pipe it to a file, then run dnstracesort to format it nicely for reading:

$ dnstrace ptr www.bratgrrl.com a.root-servers.net > bratgrrl-trace.txt

$ dnstracesort < bratgrrl-trace.txt | less

Use this to see if any DNS servers are not resolving your domain correctly, or to hunt down mysterious errors and timeouts. You can quickly grep any error messages on the ALERT keyword:

$ cat bratgrrl-trace.txt | grep ALERT

1:l.gtld-servers.net:net:192.52.178.30:ALERT:took more than 1 second

1:h2.nstld.com:com:192.5.6.30:ALERT: query failed; connection refused

1 ns1.reno.bfp.net 209.160.7.3 ALERT: query failed; timed out

1 www.entero.net 192.216.155.10 ALERT: lame server; refers to  entero.net

24.22.3 Discussion

Lots of things can go wrong in the DNS world: timeouts, lame servers, even "martians." Timeouts are usually transient, caused by network problems or server downtime. Lame servers are a bigger problem. A lame server, or lame delegation, happens when an NS record points to an incorrect host. This means that DNS requests are being directed to a server that cannot answer them, so it wastes time and resources.

Because DNS is distributed, it may not matter if a server here or there is goofed up. But if you wish to contact the admin and correct the problem, you can run a whois on the domain to find out who to contact. The Internet is chock-full of misconfigured DNS servers. Use the -H option to turn off the deluge of legalese that accompanies a whois inquiry these days:

$ whois -H pixels.net

Sadly, most DNS troubles are local: a glitch in your network, or an error in the configuration.

You can use dig to query any DNS server—not just your local server and not just DNS servers. If a server can't answer a dig request, it's broken.

24.22.4 See Also

Command-line tools to debug DNS configuration (http://cr.yp.to/djbdns/debugging.html)
dig(1), whois(1)

< Day Day Up >