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


The result might come back as:

; <<>> DiG 9.4.2 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1647
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;      IN      A

;; ANSWER SECTION: 86400 IN      CNAME   86400   IN      A       111.222.333.444

;; AUTHORITY SECTION:   71983   IN      NS   71983   IN      NS

;; ADDITIONAL SECTION:      41142   IN      A      77043   IN      A

;; Query time: 226 msec
;; 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

; <<>> DiG 9.4.2 <<>> MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37667
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;          IN      MX

;; ANSWER SECTION:   86390   IN      MX      20   86390   IN      MX      10

;; ADDITIONAL SECTION: 86390 IN    A       111.222.333.444 86390 IN     A       555.666.777.888

;; Query time: 3 msec
;; WHEN: Tue Sep 29 11:25:28 2009
;; MSG SIZE  rcvd: 113

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.

Common Questions

Finally, a few common questions:

I am not using Slicehost's DNS but I set up my DNS provider to point to my slice IP address. How do I confirm that it's working?

Use dig to test the A record for like this:

dig +short

The 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 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,

dig @

Which 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 is an alias for 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.

Want to comment?

(not made public)


(use plain text or Markdown syntax)