Introduction to dig

Made DNS changes? Not sure if they are correct? Don't want to wait for the changes to propagate before discovering a small typo?

No problem. Using the common but often ignored command 'dig', we can query DNS servers for records, specify records and even specify which DNS server to query.


Basics

The basics of the dig (domain information groper) command are very simple. Let's start by having a look at Google's records:

dig google.com

The response is as follows:

; <<>> DiG 9.3.4 <<>> google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10147
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             103     IN      A       72.14.207.99
google.com.             103     IN      A       64.233.167.99
google.com.             103     IN      A       64.233.187.99

;; AUTHORITY SECTION:
google.com.             71923   IN      NS      ns1.google.com.
google.com.             71923   IN      NS      ns2.google.com.
google.com.             71923   IN      NS      ns3.google.com.
google.com.             71923   IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         300836  IN      A       216.239.32.10
ns2.google.com.         300836  IN      A       216.239.34.10
ns3.google.com.         300836  IN      A       216.239.36.10
ns4.google.com.         300836  IN      A       216.239.38.10

;; Query time: 1 msec
;; SERVER: 208.78.97.155#53(208.78.97.155)
;; WHEN: Mon Oct  8 09:41:18 2007
;; MSG SIZE  rcvd: 212

Take it a section at a time and the output is actually incredibly informative and easy to navigate.

Firstly we have the header info which, at this point is not particularly interesting (it will be later on when we specify particular servers to query).

Next we have the Question. We asked for the DNS record of google.com.

Which gave us the Answer. In this case 3 servers responded to the domain google.com along with the IP addresses.

Next is the Authority section. In other words what Name Servers are being used by google.com.

And lastly, the Additional section. This gives the IP addresses of the Name Servers found in the Authority section.

Cached

The problem with the answer is that it actually came from local DNS servers - this could be from our ISP or indeed on our local workstation or network.

To put it another way, the records displayed above have already been propagated. It will not show very recent changes.

Remember that ISPs usually cache DNS information and may not update them more than once or twice a day - this is why we have to wait for new records to be propagated and why, on occasion, you may see your new website but your friend may still be directed the old records - their ISP has not updated the records.

Direct Query

However, that doesn't deter the intrepid Slicer as they query the DNS server directly.

Have a look at the Authority section in the google output. It lists four Name Servers. Let's directly query one of them:

dig @ns4.google.com google.com

Note the specified Name Server must be prefixed with the @ symbol.

It's the same

But isn't the output the same? Well, in this case, yes it is but note the headers:

; <<>> DiG 9.3.4 <<>> @ns4.google.com google.com

we are now querying ns4.google.com directly which will show any changes they had made that had not been fully propagated.

This is the key to checking any DNS changes you've made in the Slicehost Management Panel. Querying the records directly will show the changes before they are fully propagated.

Real Life

In this example I am going to use one of my own domains - mov2.net.

I use the Slicehost DNS Manager so I'm going to query that directly:

dig @dns1.stabletransit.com mov2.net

The output is as follows:

; <<>> DiG 9.3.4 <<>> @dns1.stabletransit.com mov2.net
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60798
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;mov2.net.                      IN      A

;; ANSWER SECTION:
mov2.net.               3600    IN      A       208.75.85.130

;; AUTHORITY SECTION:
mov2.net.               3600    IN      NS      dns1.stabletransit.com.
mov2.net.               3600    IN      NS      dns2.stabletransit.com.

;; ADDITIONAL SECTION:
dns1.stabletransit.com.      3600    IN      A       69.20.95.4
dns2.stabletransit.com.      3600    IN      A       65.61.188.4

;; Query time: 1 msec
;; SERVER: 208.78.100.222#53(208.78.100.222)
;; WHEN: Mon Oct  8 10:17:07 2007
;; MSG SIZE  rcvd: 154

Well, everything seems ok but I want to check for my mail (MX) records.

Specifying Records

To do this I simply append the record type to the query:

dig @dns1.stabletransit.com mov2.net MX

Part of the output is as follows:

;; QUESTION SECTION:
;mov2.net.                      IN      MX

;; AUTHORITY SECTION:
mov2.net.               3600    IN      SOA     dns1.stabletransit.com. hostmaster.mov2.net. 1 28800 7200 604800 3600

I have the correct question (it's querying for MX records) but no answer.

There is a good reason for that: I haven't created the records.

Create the Record

OK, now I've entered the MX records I can directly query them (you may have to wait a couple of minutes for the record to be added to the Name Server):

dig @dns1.stabletransit.com mov2.net MX

The relevant part of the output:

;; QUESTION SECTION:
;mov2.net.                      IN      MX

;; ANSWER SECTION:
mov2.net.               3600    IN      MX      0 mail.mov2.net.

Good. That seems correct to me. Now I have to wait until the records are fully propagated but I do know that they are correct.

Other Records

I can do this with any type of record by appending the record type to the command:

dig @dns1.stabletransit.com mov2.net NS

That will query the NS records only.

More

Naturally, there is more you can do with the 'dig' command and a quick:

man dig

will give detailed settings and options that are available for use.

Summary

Using the dig command can save a lot of time and effort when setting your domain's records. Although the manual will give more information for very detailed searches, the methods shown in this article should suffice for most situations.

PickledOnion.

Article Comments:

James commented Sun Dec 02 19:55:56 UTC 2007:

On Gutsy, I do not have dig, nslookup, or host. I had to do:

sudo aptitude install dnsutils

Cheers.

Sudar Muthu commented Fri Jan 04 16:40:09 UTC 2008:

Thanks James,

Even I am using Gutsy and was wondering why these commands were not working.

I am installing the dnsutils now. Thanks!

Vlad commented Sun Mar 02 02:01:27 UTC 2008:

sudo aptitude install dnsutils didn't work for me on a fresh slice. I used sudo yum install bind-utils and it worked.

movielady commented Sun Jun 15 19:24:13 UTC 2008:

FYI, dig is found in the bind-tools package on Gentoo.

Per Velschow commented Wed Sep 10 05:13:37 UTC 2008:

Trying dig on Mac OS X. I can't get the AUTHORITY SECTION to appear. Anyone know the option for that?

fil commented Mon Oct 06 14:21:39 UTC 2008:

me neither, but u get the info if u do: dig soa google.com

wytcom commented Mon Jan 12 23:31:02 UTC 2009:

My slicehost vps with centos 5 came without dig. To install:

yum install bind-utils

Owen commented Sun Oct 31 09:07:51 UTC 2010:

Really useful, cheers guys.

sysadmin commented Tue Oct 02 14:35:54 UTC 2012:

Per Velschow, on MacOS to find out the name servers for your domain (usually shown in the authority section by linux version of dig), use "dig NS you.domain.com" command.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)