Getting more out of dig
This article discusses dig's more verbose output options, then answers some common questions about dig not discussed in the previous two articles in this series, Verifying DNS configurations and Using dig with external nameservers.
Separating signal from noise
In the previous article we made all of our test responses tidy and to-the-point by adding "+short" to the options we fed the dig command. As you learn how to interpret dig results you might want to increase the detail dig returns to you by removing the "+short" option.
As an example, here's a more verbose A record test for www.domain.com:
dig www.domain.comThe result might come back as:
; <<>> DiG 9.4.2 <<>> www.domain.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1647
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;www.domain.com. IN A
;; ANSWER SECTION:
www.domain.com. 86400 IN CNAME domain.com.
domain.com. 86400 IN A 111.222.333.444
;; AUTHORITY SECTION:
domain.com. 71983 IN NS ns2.slicehost.net.
domain.com. 71983 IN NS ns1.slicehost.net.
;; ADDITIONAL SECTION:
ns1.slicehost.net. 41142 IN A 67.23.4.57
ns2.slicehost.net. 77043 IN A 173.45.224.132
;; Query time: 226 msec
;; SERVER: 10.2.104.35#53(10.2.104.35)
;; WHEN: Thu Oct 1 15:37:17 2009
;; MSG SIZE rcvd: 153That's a lot more data to parse than just the "111.222.333.444" we got with the "+short" argument in place. But remember how we needed to perform two dig tests to check MX records — one to get the name and priority of the mail servers, and another to get the IP addresses for each server?
Not with a more verbose dig test. This is the result of a "long" mailserver resolution test:
dig MX domain.com
; <<>> DiG 9.4.2 <<>> MX domain.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37667
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;domain.com. IN MX
;; ANSWER SECTION:
domain.com. 86390 IN MX 20 mail1.domain.com.
kimberconsulting.com. 86390 IN MX 10 mail.domain.com.
;; ADDITIONAL SECTION:
mail1.domain.com. 86390 IN A 111.222.333.444
mail.domain.com. 86390 IN A 555.666.777.888
;; Query time: 3 msec
;; SERVER: 10.2.104.35#53(10.2.104.35)
;; WHEN: Tue Sep 29 11:25:28 2009
;; MSG SIZE rcvd: 113Clearly, the "+short" version is much easier to read. But note how all the information you may want for a DNS MX record is delivered by one verbose dig query.
In case you were wondering, the reason the result of a regular dig query looks the way it does is that the output's format is similar to a manually configured "zone" file on a DNS server. The lines that begin with a semicolon (;) indicate comments, so if you're trying to glean information from dig's output yourself, it's the stuff not commented out that would comprise the actual configuration of the queried domain.
Common Questions
Finally, a few common questions:
I am not using Slicehost's DNS but I set up my DNS provider to point www.example.com to my slice IP address. How do I confirm that it's working?
Use dig to test the A record for www.example.com like this:
dig +short www.example.comThe IP address returned by this query should match your slice's public IP address. If it doesn't, either the A or CNAME record configured for www.example.com is incorrect (and the remedy lies in your DNS provider's DNS settings) or the change is still propagating across the Internet.
If you worry that your default DNS server is too close to your provider to reflect how the DNS records appear to the rest of the Internet, you can direct dig to use an external server with the "@" option. In this example we will use one of Google's public DNS servers, 8.8.8.8:
dig @8.8.8.8 www.example.comWhich is what we did to test Slicehost's DNS records in some previous examples.
How am I supposed to remember what order to put options in for a longer dig command?
Luckily, the order isn't really important to dig. We tried to be consistent about where we put options in our examples for the sake of readability, but for the most part you can put the destination DNS server option at the end of the command, for example, or put the domain you're checking right after "dig".
Is there a simpler way to retrieve an IP address for a domain name?
Well, yes, if all you need is the IP address a domain or subdomain ultimately points to. The "host" command, included in the DNS tools packages with dig, will return just an address and any CNAMEs for its argument:
host mail.domain.com
mail.domain.com is an alias for www.domain.com.
www.domain.com has address 111.222.333.444Dig is a more versatile tool for testing a configuration and for DNS troubleshooting, but host is easier to use for simple DNS requests.
Summary
The dig command is a powerful tool for assessing your domain's DNS configuration and how that information propagates to the rest of the Internet. Controlling the amount of information it reports and the source of the DNS information it fetches can help you focus on particular aspects of DNS troubleshooting.