How
to check your DNS records with dig
How to check your DNS records with dig
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: 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.
About the Author Gary Sims (www.hungrypenguin.net)
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.
|
