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 @ns1.slicehost.net mov2.net

The output is as follows:

; <<>> DiG 9.3.4 <<>> @ns1.slicehost.net 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      ns1.slicehost.net.
mov2.net.               3600    IN      NS      ns2.slicehost.net.
mov2.net.               3600    IN      NS      ns3.slicehost.net.

;; ADDITIONAL SECTION:
ns1.slicehost.net.      3600    IN      A       208.78.100.222
ns2.slicehost.net.      3600    IN      A       208.75.87.240
ns3.slicehost.net.      3600    IN      A       208.101.6.50

;; 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 @ns1.slicehost.net mov2.net MX

Part of the output is as follows:

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

;; AUTHORITY SECTION:
mov2.net.               3600    IN      SOA     ns1.slicehost.net. 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 @ns1.slicehost.net 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 @ns1.slicehost.net 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.