Search our site for answers
Help Docs Liquid Web Portal Domains and DNS DNS Management DNS Tool – Dig

DNS Tool – Dig

Learn to use the `dig` command to query DNS servers. Understand its output, common queries like A, MX, NS, and advanced options like +trace.
Domain Name System DNS
13 min read

Introduction

dig is a command-line tool for querying DNS name servers for information about host addresses, mail exchanges, name servers, and related information. The dig man page is somewhat lacking when it comes to examples, a shortcoming this article tries to remedy.

The source code for dig is part of the larger ISC BIND distribution. Compiling and installing BIND are topics outside the scope of this document, but on Linux systems dig is usually part of a common package: bind-tools (Gentoo), bind-utils (Red Hat, Fedora), or dnsutils (Debian).

Understanding the default output

The most typical, simplest query is for a single host. By default, however, dig is pretty verbose. You probably don’t need all the information in the default output, but it’s probably worth knowing what it is. Below is the full and annotated query of the following command.

$ dig www.isc.org
$ dig www.isc.org
; <<>> DiG 9.2.3 <<>> www.isc.org
;; global options:  printcmd
 ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43071
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;www.isc.org.                   IN      A
 ;; ANSWER SECTION:
www.isc.org.            600     IN      A       204.152.184.88
 ;; AUTHORITY SECTION:
isc.org.                2351    IN      NS      ns-int.isc.org.
isc.org.                2351    IN      NS      ns1.gnac.com.
isc.org.                2351    IN      NS      ns-ext.isc.org.
 ;; ADDITIONAL SECTION:
ns1.gnac.com.           171551  IN      A       209.182.216.75
ns-int.isc.org.         2351    IN      A       204.152.184.65
ns-int.isc.org.         2351    IN      AAAA    2001:4f8:0:2::15
 ;; Query time: 2046 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 27 08:22:26 2004
;; MSG SIZE  rcvd: 173

Now lets go ahead and do a deep dive into each section of the command’s output.

 ; <<>> DiG 9.2.3 <<>> www.isc.org
 ;; global options:  printcmd

The opening section of dig’s output tells us a little about itself (version 9.2.3) and the global options that are set (in this case, printcmd). This part of the output can be quelled by using the +nocmd option, but only if it’s the very first argument on the command line (even preceding the host you’re querying).

;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43071
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

Here, dig tells us some technical details about the answer received from the DNS server. This section of the output can be toggled using the +[no]comments option—but beware that disabling the comments also turns off many section headers.

 ;; QUESTION SECTION:
 ;www.isc.org.                   IN      A

In the question section, dig reminds us of our query. The default query is for an Internet address (A). You can turn this output on or off using the +[no]question option.

 ;; ANSWER SECTION:
 www.isc.org.            600     IN      A       204.152.184.88

Finally, we get our answer: the address of www.isc.org is 204.152.184.88. I don’t know why you’d ever want to turn off the answer, but you can toggle this section of the output using the +[no]answer option.

 ;; AUTHORITY SECTION:
 isc.org.                2351    IN      NS      ns-int.isc.org.
 isc.org.                2351    IN      NS      ns1.gnac.com.
 isc.org.                2351    IN      NS      ns-ext.isc.org.

The authority section tells us what DNS servers can provide an authoritative answer to our query. In this example, isc.org has three name servers. You can toggle this section of the output using the +[no]authority option.

;; ADDITIONAL SECTION:
 ns1.gnac.com.           171551  IN      A       209.182.216.75
 ns-int.isc.org.         2351    IN      A       204.152.184.65
 ns-int.isc.org.         2351    IN      AAAA    2001:4f8:0:2::15

The additional section typically includes the IP addresses of the DNS servers listed in the authority section. This section of the output can be toggled with the +[no]additional option.

 ;; Query time: 2046 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Fri Aug 27 08:22:26 2004
 ;; MSG SIZE  rcvd: 173

The final section of the default output contains statistics about the query; it can be toggled with the +[no]stats option.

What can I discover?

dig will let you perform any valid DNS query, the most common of which are A (the IP address), TXT (text annotations), MX (mail exchanges), NS name servers, or the omnibus ANY.

 # get the address(es) for yahoo.com
 dig yahoo.com A +noall +answer
 
 # get a list of yahoo's mail servers
 dig yahoo.com MX +noall +answer
 
 # get a list of DNS servers authoritative for yahoo.com
 dig yahoo.com NS +noall +answer
 
 # get all of the above
 dig yahoo.com ANY +noall +answer

More obscurely, for the present anyway, you can also poll for a host’s IPv6 address using the AAAA option.

 dig www.isc.org AAAA +short

If the domain you want to query allows DNS transfers, you can get those, too. The reality of life on the Internet, however, is that very few domains allow unrestricted transfers these days.

 dig yourdomain.com AXFR

How do I …

Get a short answer?

When all you want is a quick answer, the +short option is your friend:

$ dig www.isc.org +short
 204.152.184.88

Get a not-quite-so-short answer?

Note that a short answer is different from only an answer. The way to get a detailed answer, but without any auxiliary information, is to turn off all the results (+noall) and then turn on only those sections you want.

Here’s a short answer followed by only an answer; the latter includes all the configuration information, including time-to-live (TTL) data, displayed in a format compatible with BIND configuration files.

$ dig fsf.org mx +short
 20 mx20.gnu.org.
 30 mx30.gnu.org.
 10 mx10.gnu.org.
 $ dig +nocmd fsf.org mx +noall +answer
 fsf.org.                3583    IN      MX      30 mx30.gnu.org.
 fsf.org.                3583    IN      MX      10 mx10.gnu.org.
 fsf.org.                3583    IN      MX      20 mx20.gnu.org.

Get a long answer?

According to its man page, the +multiline option will give you an answer with “the SOA records in a verbose multi-line format with human-readable comments.” In general, the answers retrieved using the +multiline option will appear more like BIND config files than they will without it.

$ dig +nocmd ogi.edu any +multiline +noall +answer
 ogi.edu.   14267 IN A 129.95.59.31
 ogi.edu.   14267 IN MX 5 cse.ogi.edu.
 ogi.edu.   14267 IN MX 15 hermes.admin.ogi.edu.
 ogi.edu.   14267 IN SOA zeal.admin.ogi.edu. hostmaster.admin.ogi.edu. (
                    200408230  ; serial
                    14400      ; refresh (4 hours)
                    900        ; retry (15 minutes)
                    3600000    ; expire (5 weeks 6 days 16 hours)
                    14400      ; minimum (4 hours)
                    )
 ogi.edu.   14267 IN NS zeal.admin.ogi.edu.
 ogi.edu.   14267 IN NS cse.ogi.edu.
 ogi.edu.   14267 IN NS fork.admin.ogi.edu.

Do a reverse lookup?

Use the -x option to lookup the main hostname associated with an IP address.

 $ dig -x 204.152.184.167 +short
 mx-1.isc.org.

Query a different nameserver?

Just specify it on the command line:

dig @ns1.google.com www.google.com

Occasionally you may find that the various authoritative nameservers have different dns information causing a failure to load properly when the bad information is queried. This is especially prevalent when the name servers for a domain are hosted on different servers.

It is always a good idea to dig the dns record @ each of the authoritative nameservers listed under the whois information to confirm the DNS information is set and propagating correctly.

Do bulk lookups?

If you want to look up a large number of hostnames, you can put them in a file (one name per line) and use the -f option to query each one in turn.

 # do full lookups for a number of hostnames
 dig -f /path/to/host-list.txt
 # the same, with more focused output
 dig -f /path/to/host-list.txt +noall +answer

Note: dig versions up to and including 9.2.3 are unable to do reverse lookups using the -f option

MX records

Searching for MX will pull the mail exchange information specifically.

Example:

dig mx liquidweb.com

Result:

;; ANSWER SECTION:
liquidweb.com.		30	IN	MX	5 mx02.liquidweb.com.
liquidweb.com.		30	IN	MX	5 mx03.liquidweb.com.
liquidweb.com.		30	IN	MX	5 mx01.liquidweb.com.

SPF or DKIM records

Asking for txt will pull spf, dkim and any other txt records that may be present.

Example:

dig txt liquidweb.com

Result:

liquidweb.com.		30	IN	TXT	"v=spf1 a:mxgate-02.liquidweb.com a:mxgate-03.liquidweb.com a:email.liquidweb.com a:mxgate-02.liquidweb.com a:agile.liquidweb.com a:swift.liquidweb.com mx:liquidweb.com include:support.zendesk.com include:smtp.zendesk.com ~all"

Nameserver records

Searching for NS will list the name servers set in the zone file.

Example:

dig ns liquidweb.com

Result:

;; ANSWER SECTION:
liquidweb.com.		900	IN	NS	ns1.liquidweb.com.
liquidweb.com.		900	IN	NS	ns.liquidweb.com.

SOA

Searching for soa will provide start of authority information.

Example:

dig soa liquidweb.com

Result:

liquidweb.com.		900	IN	SOA	ns.liquidweb.com. root.liquidweb.com. 2013031266 3600 600 172800 7200

Verifying DNS mappings

An improperly configured DNS setup can be really annoying. You want to make sure that your mappings work both ways:

1.   Each hostname should resolve to an address, and that address ought to resolve back to the proper hostname.
2.   If an address on your subnet(s) has been assigned a reverse pointer to a hostname, that hostname ought to point back to the original address.

There are exceptions to those two rules, of course. A CNAME will resolve to another hostname first, and only then to an address. Sometimes multiple hostnames will point to the same address, but that address will have only one reverse pointer.

Still, it’s good to know that your basic mappings work as expected.

Tracing dig’s path

Perhaps you’re a devotee of traceroute and like to watch how to get from point A to point B. You can do a similar thing with dig’s +trace option.

 dig domain.com +trace

You’ll see dig head to the root name servers, then to the servers responsible for all the *.com domains, and finally to the name servers responsible for domain.com. An example of what this may look like is below.

$ dig philmil.com +trace

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> philmil.com +trace
;; global options: +cmd
. 270 IN NS h.root-servers.net.
. 270 IN NS f.root-servers.net.
. 270 IN NS m.root-servers.net.
. 270 IN RRSIG NS 8 0 518400 20240123170000 20240110160000 30903 . NaUD6RHSVZGaNvoNuJVeZYW92t1toI5o0k63C1NNh5YFAZJJuPoqBffX /FQ8b1Tld6fbYKpWw4Dg7zpyKJ2uShMqSPwD3E+Ov+ntPNhaIF4XIAcC eNifnVp13glUNb0+6wrNpodbvKQfSp7IdLCkNIOnzPOeYhmVNrxXRo08 icWn6m0uEhxs+bE36xnNzGPdMfrOJ47p9yNOkuH2GQ2bQA/DHqCntwT0 e+LQDwzxZNvPJQmi62tY1bXZzXuaBW7U9YTRASeyr/8TS+tVK9gYYF+K oRSfncK+mIc46QgLWarwVqA9mSi8A3pxaQDHtGsEPZ9bDsefepwXV+Nv acUdnA==
;; Received 1125 bytes from 10.30.7.126#53(10.30.7.126) in 47 ms
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for philmil.com failed: network unreachable.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com. 86400 IN RRSIG DS 8 1 86400 20240123170000 20240110160000 30903 . AWOPczZ+XTDBXDMILHX5ImUeo7jb4styZnJYw8q5sUcjn+LZu7fjO2gz BWUhlTux97JQTPIFKx208P0m5SJ+IQZm5w5KIhiV75KAouBzONLWQZ0r Iv3FyJLhpsFtKIDlQvEmiK3y1zya+oRO55IaNljTJusFsHaafKkxO5Ag srQ8lDd1ozv8vMxe82S0leNrFYmKglQLhUJe8cB89wUeAsCHgrRzCuH1 Cr27ihOISye03jQV24f0s4RHUVARkAgxT7REfHZ4ldWOoL7ftE5yyCRe xq1KdaoGMhNF63Z0h+hAekvsE8PeAZiOp5EAvid/4TITixQSKrmkALE/ o7omHg==
;; Received 1171 bytes from 193.0.14.129#53(k.root-servers.net) in 219 ms
;; UDP setup with 2001:503:83eb::30#53(2001:503:83eb::30) for philmil.com failed: network unreachable.
;; UDP setup with 2001:500:856e::30#53(2001:500:856e::30) for philmil.com failed: network unreachable.

philmil.com. 172800 IN NS ns.liquidweb.com.
philmil.com. 172800 IN NS ns1.liquidweb.com.

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240117052616 20240110041616 46171 com. uCgVKi9BtwcO9D/83FSxaDVZyqKD1weIPDY6xv1nQLndL77EM/17Wh/X qYJYqaQDa2vwPFZChYKgInksHXny6A==
IMRVQ3KLPANMLP784DAFCUQKHSPKSHNM.com. 86400 IN NSEC3 1 1 0 - IMRVU4TPUOEAL5BBTMSRKCR3U0S5GOT7 NS DS RRSIG
IMRVQ3KLPANMLP784DAFCUQKHSPKSHNM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240115074744 20240108063744 46171 com. FOGEhEkUpEb6cKajshQ4AtLc9hUs4EkPwBAGxmf4DRvwFyeZFbZrsmhu jIMT4qNlP+SBarKD048Ubzq/swCVHQ==
;; Received 474 bytes from 192.12.94.30#53(e.gtld-servers.net) in 35 ms

philmil.com. 3600 IN A 67.225.210.172

Using dig +trace can be helpful when trying to confirm if a DNS issue is at the registrar or something set within the sites DNS zone file. Normally you will see this kind of thing if you attempt to dig a domain, but no records are reporting. In that case we do a dig +trace and if we’re not seeing the sites Nameserver records reporting (the one reporting when you Whois the domain), that points towards either the change to the Nameserver is still propagating from the registrar, or that there is something at the registrar’s end that is holding up the change. Either way the customer would most likely want to contact the sites registrar to make sure there isn’t an issue on their end.

But if the dig +trace shows it is hitting the set Nameservers (like in the above example), then it points towards there being an issue with the DNS Zone file for the site on the Nameservers. 

Interpreting TTL numbers

If you ask your local DNS server for an Internet address, the server figures out where to find an authoritative answer and then asks for it. Once the server receives an answer, it will keep the answer in a local cache so that if you ask for the same address again a short time later, it can give you the answer quickly rather than searching the Internet for it all over again.

When domain administrators configure their DNS records, they decide how long the records should remain in remote caches. This is the TTL number (usually expressed in number of seconds).  Typically, a remote server will only cache those records for the length of time specified by the TTL.

After that, the remote server will flush its local cache and ask again for an authoritative answer.  When you use dig to query a DNS server concerning a certain record, the server will tell dig the time (in seconds) that record will remain in cache.

For example, as of this writing, the TTL for the MX records for the gmail.com domain is 300 seconds. The gmail.com admins are asking that remote servers cache their MX records for no more than five minutes. So when you first ask for that record set, dig will report a TTL of 300.

 $ dig +nocmd gmail.com MX +noall +answer
 gmail.com.        300     IN      MX      20 gsmtp57.google.com.
 gmail.com.        300     IN      MX      10 gsmtp171.google.com.

If you ask a few seconds later, you’ll see the TTL number reduced by approximately the number of seconds you waited to ask again.

$ dig +nocmd gmail.com MX +noall +answer
 gmail.com.        280     IN      MX      10 gsmtp171.google.com.
 gmail.com.        280     IN      MX      20 gsmtp57.google.com.

If your timing is good, you can catch the record at the very end of its life.

$ dig +nocmd gmail.com MX +noall +answer
 gmail.com.        1       IN      MX      10 gsmtp171.google.com.
 gmail.com.        1       IN      MX      20 gsmtp57.google.com.

After that, the DNS server you’re querying will “forget” the answer to that question, so the whole cycle will start over again (in this example, at 300 seconds) the next time you perform that query.

Was this article helpful?