Making Full Use Of ‘Dig’ In Linux

Dig (domain information groper) is to Linux, what nslookup is to Windows. Be it just a bit more powerful. Here are just some of possibilities in using it, to query different nameservers, query for specific nameserver records (A, AAAA, MX, CNAME, TXT), and so on.

The table of contents


Installing dig

First of, a little "How To Install Dig".

If you're running a redhat based release (centos, fedora, red hat), you can use yum.

yum install bind-utils

For anything Debian based, there's apt-get.

apt-get install bind-utils

(And for those who use Gentoo, there's 'emerge bind-tools')

Basic usage of dig

Now let's get started. There's the basic usage of dig, to get the output of the nameserver records of a certain domain, using your currently configured nameservers (/etc/resolv.conf). This will most likely query your ISP's nameserver(s), or the ones provided to you by your company.

Here's the command to issue: dig www.mattiasgeniar.be . This will start a query to retrieve the nameserver records for the domain "www.mattiasgeniar.be".

[root@vps ~]# dig www.mattiasgeniar.be

; <<>> DiG 9.3.4-P1 <<>> www.mattiasgeniar.be
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48084
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;www.mattiasgeniar.be.          IN      A

;; ANSWER SECTION:
www.mattiasgeniar.be.   78003   IN      CNAME   mattiasgeniar.be.
mattiasgeniar.be.       78003   IN      A       193.239.210.183

;; AUTHORITY SECTION:
mattiasgeniar.be.       78003   IN      NS      ns.mattiasgeniar.be.

;; ADDITIONAL SECTION:
ns.mattiasgeniar.be.    78003   IN      A       193.239.210.183

;; Query time: 9 msec
;; SERVER: 193.239.211.254#53(193.239.211.254)
;; WHEN: Fri Aug 29 20:06:27 2008
;; MSG SIZE  rcvd: 101

This will teach use quite a few things, right of the bat. It's peanut-butter-analyze-time!

;; QUESTION SECTION:
;www.mattiasgeniar.be.          IN      A

The question section actually just copies our request to the nameserver. We ask it to tell us which A record belongs to the hostname "www.mattiasgeniar.be". This is the default query that is being launched if you provide no other options with the dig command, other than a hostname.

;; ANSWER SECTION:
www.mattiasgeniar.be.   78144   IN      CNAME   mattiasgeniar.be.
mattiasgeniar.be.       78144   IN      A       193.239.210.183

This tells us that "www.mattiasgeniar.be" is a CNAME record, that refers to the hostname "mattiasgeniar.be" . "mattiasgeniar.be" in return, is an A record that points to the IP address 193.239.210.183.

This kind of configuration is usually accomplished by defining 1 A record that points to an IP address, and a catch-all CNAME " *.mattiasgeniar.be" that refer to that specific A record. It saves you a lot of time if you ever decide to move a website, since you'll only need to update 1 IP address (defined in the A record), and not several -- defined in more seperate A records.

;; AUTHORITY SECTION:
mattiasgeniar.be.       78003   IN      NS      ns.mattiasgeniar.be.

The NS record-type learns us which machine is in charge of this domain, in this case it's the server located at "ns.mattiasgeniar.be". The nameserver at that address is the authoritative name server, and will be queried when someone tries to locate the domain "www.mattiasgeniar.be".

;; ADDITIONAL SECTION:
ns.mattiasgeniar.be.    78003   IN      A       193.239.210.183

This then tells us that the authoritative nameserver "ns.mattiasgeniar.be" is located at the IP address 193.239.210.183. By default, the additional section will perform a lookup for the host listed in the authority section.

More info, less output: +short

If that output is all a bit much, if you just want to do a simple lookup, you can shorten it by supplying the +short parameter.

[root@vps ~]# dig www.mattiasgeniar.be +short
mattiasgeniar.be.
193.239.210.183


Use dig to query for a specific record

Now, on to more specific things. Say you want to query your current nameservers, for the MX record of a domain? You can easily do this by defining the type of record in the dig command. Just add "MX" at the end, to query for the MX records.

[root@vps ~]# dig www.mattiasgeniar.be MX
....
;; ANSWER SECTION:

 www.mattiasgeniar.be.   77269   IN      CNAME   mattiasgeniar.be.
mattiasgeniar.be.       17124   IN      MX      10 mail.mattiasgeniar.be.

....

The actual reply to your request, lies in the ANSWER SECTION (shown in bold). It tells you that the MX record points to "mail.mattiasgeniar.be", and that it has a priority of 10. Since there's only 1 MX record defined, the priority doesn't mean much here.

If there are several MX records, it means more than 1 mailserver is configured to receive mail for this domain. The priority given will determine in which order they are contacted to deliver the e-mail. The mailserver with the lowest priority will be contacted first.

If multiple MX records exist with the same priority, they'll be contacted "at random". This technique is called Round Robin and often used to spread the load amongst 2 or more mailservers, without requiring some sort of loadbalancer.

Query a specific nameserver

You can also use dig to query other nameserver, and see what information they hold about a domain. It can help you bypass the (sometimes lengthy) DNS updates of your ISP, and see if the nameservers are configured properly.

[root@vps ~]# dig www.mattiasgeniar.be @ns1.nucleus.be
....

Using the @ , you can specify which nameserver you want to ask your query to. In this case, we're asking "ns1.nucleus.be" to tell us where "www.mattiasgeniar.be" points to.

This allows for certain combinations of course, what if we want to see the MX records of a domain, ask that query to a different nameserver than our defaults (defined in /etc/resolv.conf) and only display the short reply?

[root@vps ~]# dig www.mattiasgeniar.be @ns1.nucleus.be MX +short
mattiasgeniar.be.
10 mail.mattiasgeniar.be.

Just tick all parameters right after each other. This'll query the nameserver "ns1.nucleus.be" for the MX records of the domain, and the +short parameter tells us to not overload us with information, but only display the short result.

Flags used by dig output

And in case you've noticed, every time we perform a lookup of a domain through dig, there's some extra information in the header of the output (right before the actual answer of our query is displayed).

[root@vps ~]# dig www.mattiasgeniar.be @ns1.mattiasgeniar.be

; <<>> DiG 9.3.4-P1 <<>> www.mattiasgeniar.be @ns1.mattiasgeniar.be
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21271
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

The flags are useful here. But what do those flags in DNS terms mean?

  • AA: Authorative Answer: the nameserver that answered the query is the authorative (responsible) nameserver for that domain. Record shown in this query are those that will be known throughout the world.
  • RD: Recursion Desired (see example below).
  • RA: Recursion Available.
  • QR: Query Response: the answer we received seems pretty reasonable, and could be real.


Query the root nameservers

And to show the "recursion" meaning, in DNS terms, here's the nameserver query for the domain "mattiasgeniar.be", when asked to one of the Root Servers.

[root@vps ~]# dig @a.root-servers.net www.mattiasgeniar.be

; <<>> DiG 9.3.4-P1 <<>> @a.root-servers.net www.mattiasgeniar.be
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4954
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 10

;; QUESTION SECTION:
;www.mattiasgeniar.be.          IN      A

;; AUTHORITY SECTION:
be.                     172800  IN      NS      BRUSSELS.NS.DNS.be.
be.                     172800  IN      NS      MILANO.NS.DNS.be.
be.                     172800  IN      NS      C.NS.DNS.be.
be.                     172800  IN      NS      AMSTERDAM.NS.DNS.be.
be.                     172800  IN      NS      PRAGUE.NS.DNS.be.
be.                     172800  IN      NS      B.NS.DNS.be.
be.                     172800  IN      NS      LONDON.NS.DNS.be.
be.                     172800  IN      NS      X.DNS.be.
be.                     172800  IN      NS      A.NS.DNS.be.

Loads of information there ... First of, the "authority section" tells us the root nameservers for the .BE top level domain. These nameservers should be queried for the correct nameserver lookup. The flag "rd" means "recursion desired", and tells us we should consult one of the authoritative nameservers given -- because the root nameserver cannot tell us the answer.

I think I'll leave it at that ... there's lots more to cover about dig, and DNS in general, but I guess if you made it this far through the explanation -- you should at least deserve a tap on the shoulder. Congratulations! :-)

One comment on “Making Full Use Of ‘Dig’ In Linux
  1. Kim says:

    Lookup Name Servers of a website using this free online tool at: tools.khrido.com/webtools/mx-ns-soa-lookup.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Advertisement

Why ads?

I'm glad you made it to this blogpost. I hope it helps solve your problem. So why then do I show ads on the site? Writing content, testing it and making sure the layout isn't totally b0rked takes time. A lot of time. The ads are a way to pay back a small portion of that time.

And as you know running a site costs (a bit of) money: the domain name, webhosting, time spent writing and updating content, ... So if you like the content of this blog, consider disabling your AdBlocker for this domain. Thanks!

Looking for help?

Tired of fixing all these tech-problems yourself? We've got an excellent team at Nucleus, a top-class Belgian hosting provider, that can help you.

Discover our Managed Hosting, where skilled engineers manage your servers and keep them up-to-date, so you can focus on your core business. We use a variety of Configuration Management Systems such as Puppet to make sure every config is reviewed, unit-tested and guaranteed to be working.

Want to get in touch? Find me as @mattiasgeniar on Twitter or via the contact-page on this blog.