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? Here’s how to check your DNS records with a tool called dig.
DNS is an Internet service that translates domain names into IP addresses. Each time you use a domain name, DNS translates the name into the corresponding IP address. In order to do the translation DNS holds records for each domain. The most important are the A, CNAME, and MX records. The A record stores the host IP address. The CNAME is an alias record, which is used to give multiple aliases to a single computer. The MX record is the mail exchange record, which tells mail servers how to route email for this domain.
For example, the DNS record for www.newsforge.com looks like this:
www.newsforge.com CNAME newsforge.com. newsforge.com A 66.35.250.177
This says 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 newsforge.com with your Web browser, your computer will query DNS for the IP address and then make a connection over the Internet to the Web server at that address and start downloading the page.
Dig
To query DNS and see the records it holds, you can use a software tool called dig that queries DNS servers directly. Dig comes standard with all the major Linux distributions, and is useful for verifying and troubleshooting 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 command causes dig to look up the A record for the domain name www.hungrypenguin.net. To do this dig starts by looking in your /etc/resolv.conf file and querying the DNS servers listed there. The response from the DNS server is what dig displays:
; <<>> 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
Lines beginning with ; are comments that are not part of the information received from the DNS server, but 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 option 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 one answer, two pieces of information in the authority section, and a further two 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, which 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).
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 other useful information. The authority section contains a list of name servers that are responsible for the domain name — those that can always give an authoritative answer. Here we find two name servers listed, which are the name servers of the company with which the domain was registered. To save an extra lookup, dig lists the IP addresses of those name servers in the additional section.
Lastly there are some stats about the query. You can turn off these stats 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:
67.15.117.250
However, for diagnosing DNS problems, you generally need fuller output. You can find a happy medium by putting the following lines into a file called .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, but you can specify other records for it to examine. The MX or Mail eXchange record tells mail servers how to route the email for the domain. You can examine your MX records using dig like this:
dig hungrypenguin.net MX
Note that we asked for hungrypenguin.net and not www.hungrypenguin.net, since normally when you send email to someone, you send it to the domain and not to one of the subdomains like www or ftp —
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
, not
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
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 that handles the email for the hungrypenguin.net domain. There is also a backup server (mx1) that handles the mail if mx0 is unavailable for any reason. The 10 and the 20 are the preference values for the domain; lower values are preferred over the higher ones.
Querying other DNS servers
By default dig queries the DNS servers listed in your /etc/resolv.conf file, which are normally the DNS servers of your ISP. However, it can also be useful to query other DNS servers, and particularly the authoritative DNS server.
If you need to modify your DNS records, for example when migrating your Web site 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 that domain’s ISP’s DNS server. To use a different name server, call dig with the first parameter of @nameserver. For example you 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 that has responsibility for the hungrypenguin domain. One way to verify the authority of the answer is to look for the aa flag in the header.
Real life
Recently I migrated the hungrypenguin.net Web site from one hosting provider to another. I changed the DNS settings using the control panel software of the domain registration company. I updated the A record to contain the IP address of the new Web server and the MX record to the names of the new mail servers. As expected, because of propogation time delays, my ISP still showed the old IP address after the change. To check the updates, I used dig to query the authoritative DNS server. There DNS showed the new IP address — but the MX records contained a mistake! I quickly returned to the control panel software and rectified the mistake. After a final check, I could sit back and relax, knowing that the next day DNS nodes 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.
