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
- Basic usage + output analysis
- More info, less output
- Querying for a specific record (TXT, MX, ...)
- Query a specific nameserver
- Different header-flags
- Query the root nameservers
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
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 188.8.131.52 ;; AUTHORITY SECTION: mattiasgeniar.be. 78003 IN NS ns.mattiasgeniar.be. ;; ADDITIONAL SECTION: ns.mattiasgeniar.be. 78003 IN A 184.108.40.206 ;; Query time: 9 msec ;; SERVER: 220.127.116.11#53(18.104.22.168) ;; 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 22.214.171.124
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 126.96.36.199.
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 188.8.131.52
This then tells us that the authoritative nameserver "ns.mattiasgeniar.be" is located at the IP address 184.108.40.206. 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. 220.127.116.11
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! :-)