Have you just made DNS changes but aren't sure if they're 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 (domain information groper) we can query DNS servers for records, specify records, and even specify which DNS server to query.

Installing

You may already have dig installed. To find out, from your command prompt run:

which dig

If you got a message that the system couldn't find dig then it's a quick step to install it.

Ubuntu and Debian

For Ubuntu, Debian, and other distributions that use the apt package manager, run:

sudo aptitude install dnsutils

CentOS, Red Hat, Fedora

For CentOS, Red Hat, Fedora, and other distributions using the yum package manager, run:

sudo yum install bind-utils

Basics

The basics of the dig command are very simple. Let's start by having a look at Google^TM'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.

• Header info - At this point, the header info is not particularly interesting (it will be later on when we specify particular servers to query).
• QUESTION SECTION - We asked for the DNS record of google.com.
• ANSWER SECTION - Which gave us the Answer. In this case, three servers responded to the domain google.com along with the IP addresses.
• AUTHORITY SECTION - In other words, what Name Servers are being used by google.com?
• 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 you if you 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

Notice that 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 notice the headers:

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

We are now querying directly ns4.google.com,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 Cloud Server Control Panel. Querying the records directly will show the changes before they are fully propagated.

Specifying Records

To do this, append the record type to the query:

# dig @ns4.google.com google.com MX

The dig query responds back with the following answer:

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

;; ANSWER SECTION:
google.com.         10800  IN     MX     10 smtp4.google.com.
google.com.         10800  IN     MX     10 smtp1.google.com.
google.com.         10800  IN     MX     10 smtp2.google.com.
google.com.         10800  IN     MX     10 smtp3.google.com.

Other Records

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

# dig @ns4.google.com google.com NS

That will query the NS records only.

More

Naturally, there is more you can do with the dig command, and for a list of detailed settings and options available, just do a quick:

# man dig

Summary

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

This concludes the First 48 Hour Cloud Essentials - the most important information that we thought you should have when starting as a new customer with us. Thank you for reading through to the end, though its really just the beginning! We hope you found the articles here easy to understand, and that the information helps you avoid future pifalls. Good luck, and please let us know what else we do can to make the Cloud easy for you to use.

Back to the First 48 Guide Page