How to check your DNS records with dig

By Gary Sims

Originally published at www.newsforge.com

Introduction

Have you ever wanted to query the Domain Name System (DNS) to discover what information it holds about your domain? Do you have some important changes to make to your DNS records and need a way to verify your changes? In this tutorial you will learn how to check your DNS records with a tool called dig.

DNS

DNS is an Internet service that translates domain names into IP addresses. Each time you use a domain name, DNS is used to translate the name into the corresponding IP address. To do the translation DNS holds records for each domain. There are theoretically over 50 different types of DNS record for the Internet. However the most important are the A, CNAME and MX records. The A record stores the host IP address. The CNAME is an alias record and the MX record is the mail exchange record which tells mail servers how to route the email. A full list of record types can be found at: http://www.iana.org/assignments/dns-parameters.

For example, the A record for www.newsforge.com looks like this:

www.newsforge.com	CNAME		newsforge.com.
newsforge.com		A       	66.35.250.177

This tells us that www.newsforge.com is an alias for newsforge.com and that newsforge.com has the IP address 66.35.250.177. If you want to read the newsforge site with your web browser, your computer will query DNS for the IP address and then make a network connection (over the Internet) to the newsforge server and start downloading the pages.

Dig

To query DNS and see the records which it holds, you can use a tool called dig. Dig queries DNS servers directly and it comes as standard with all the major Linux distributions. Dig is a very useful tool for webmasters and site administrators to verify and troubleshoot DNS problems.

To check the record for your domain run dig with your domain name as the parameter. For example:

	dig www.hungrypenguin.net

This will cause dig to lookup the A record for the domain name www.hungrypenguin.net. To do this dig will look in your /etc/resolv.conf file and query the DNS servers listed there. The response from the DNS server is what is displayed:

; <<>> DiG 9.2.4 <<>> www.hungrypenguin.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28017
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.hungrypenguin.net.         IN      A

;; ANSWER SECTION:
www.hungrypenguin.net.  75583   IN      A       67.15.117.250

;; AUTHORITY SECTION:
hungrypenguin.net.      75583   IN      NS      ns2.hosteurope.com.
hungrypenguin.net.      75583   IN      NS      ns.hosteurope.com.

;; ADDITIONAL SECTION:
ns.hosteurope.com.      158892  IN      A       212.67.202.2
ns2.hosteurope.com.     158892  IN      A       212.67.203.246

;; Query time: 2474 msec
;; SERVER: 193.231.237.2#53(193.231.237.2)
;; WHEN: Tue Apr  5 16:10:48 2005
;; MSG SIZE  rcvd: 136

The first thing to note is that lines beginning with ; are comments which do not make up part of the actual answer received from the DNS server, however they do reflect some of the low level protocol used in making the query.

The first two lines tell us the version of dig (9.2.4), the command line parameters (www.hungrypenguin.net ) and the query options (printcmd). The printcmd options means that the command section (the name given to these first two line) is printed. You can turn it off by using the option +nocmd.

Next dig shows the header of the response it received from the DNS server. Here it reports that an answer was obtained from the query response (opcode: QUERY) and that the response contains 1 answer, 2 pieces of information in the authority section and a further 2 in the additional section. The flags are used to note certain things about the DNS server and its response. For example, the RA flag shows that recursive queries are available.

Next comes the question section, this simply tells us the query, which in this case is a query for the A record of www.hungrypenguin.net. The IN means this is an Internet lookup (in the Internet class).

Now for the answer. The answer section tells us that www.hungrypenguin.net has the IP address 67.15.117.250.

Along with the IP address the DNS record contains some more useful information. In the authority section there is a list of name servers which are responsible for the domain name, those which can always give an authoritative answer. Here we find two name servers listed. These are in fact the name servers of the company with which the domain was registered. To save an extra lookup the IP addresses of those name servers are listed in the additional section.

Lastly there are some stats about the query. These stats can be turned off using the +nostats option.

By default dig is quite verbose. One way to cut down the output is to use the +short option:

	dig www.hungrypenguin.net +short

Which will drastically cut the output to just:

	67.15.117.250

However for diagnosing DNS problems fuller output is needed. A happy medium can be found by putting the following lines into .digrc in your home directory:

+nocmd
+nostats
+noquestion

Querying different types of DNS records

By default dig looks for the A record of the domain specified. However, as mentioned earlier, there are many types of domain records. Along with the A record another important one is the MX record. The Mail eXchange record tells mail servers how to route the email. You can examine your MX records using dig like this:

	dig hungrypenguin.net MX

The first thing to note is that the dig is for hungrypenguin.net and not www.hungrypenguin.net. This is because normally when you send email to someone, you send it to the domain and not to one of the subdomains like www or ftp. The webmasters email address at hungrypenguin is webmaster@hungrypenguin.net not webmaster@www.hungrypenguin.net.

The salient part of the response is:

;; ANSWER SECTION:
hungrypenguin.net.      86400   IN      MX      10 mx0.123-reg.co.uk.
hungrypenguin.net.      86400   IN      MX      20 mx1.123-reg.co.uk.

This tells us that there is a mail server called mx0.123-reg.co.uk which will handle the email for the hungrypenguin.net domain. There is also a backup server (mx1) which handle the mail if mx0 is unavailable for any reason. The 10 and the 20 are the preference values for the domain. The lower values are preferred over the higher ones.

Querying other DNS servers

As mentioned earlier by default dig will query the DNS servers listed in your /etc/resolv.conf. These are normally the DNS servers of your ISP. However it can also be very useful to query other DNS servers, particularly the authoritative DNS server.

If you need to modify your DNS records, for example when migrating your website from one hosting provider to another, it is essential to ensure that your DNS records are updated correctly. The problem with DNS updates is that they can take up to 48 hours to propagate through the Internet. For a successful migration it is important to know that your DNS records are correct now rather than waiting 48 hours to discover that they contain an error!

Earlier we saw that ns.hosteurope.com is the authoritative (responsible) name server for the hungrypenguin.net domain. That information came from my ISP's DNS server. To use a different name server call dig with the first parameter as @nameserver. For example we can query ns.hosteurope.com directly like this:

	
dig @ns.hosteurope.com www.hungrypenguin.net 

This will return a response directly from the name server which has responsibility for the hungrypenguin domain. One way to verify the authority of theanswer is to look for the aa flag in the header.

Real life

Recently the hungrypenguin.net website was migrated from one hosting provider to another. The DNS settings were changed using the control panel software of the domain registration company. The A record was updated to contain the IP address of the new web server and the MX records were updated to the names of the new mail servers. As expected, after the change my ISP still showed the old IP address. To check the updates dig was used to query the authoritative DNS server. There DNS showed the new IP address. The MX records were also checked... they contained a mistake! Quickly back to the control panel software and the mistake was rectified. Now the webmaster could sit back and relax knowing that tomorrow DNS around the world would have the correct information.

Gary Sims has a degree in Business Information Systems from a British university.He worked for 10 years as a software engineer and is now a freelance Linux consultant and writer.