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:
The result might come back as:
; <<>> DiG 9.4.2 <<>> www.domain.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<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 dns2.stabletransit.com. domain.com. 71983 IN NS dns1.stabletransit.com. ;; ADDITIONAL SECTION: dns1.stabletransit.com. 41142 IN A 18.104.22.168 dns2.stabletransit.com. 77043 IN A 22.214.171.124 ;; 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: 153
That'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<
Clearly, 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.
Finally, a few common questions:
Use dig to test the A record for www.example.com like this:
dig +short www.example.com
The IP address returned by this query should match your cloud server'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, 126.96.36.199:
dig @188.8.131.52 www.example.com
Which is what we did to test DNS records in some previous examples.
Fortnately, 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".
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.444
Dig is a more versatile tool for testing a configuration and for DNS troubleshooting, but host is easier to use for simple DNS requests.
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.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License