The command dig is a tool for querying name servers for information about various records like A, MX, NS, and related information.
dig live.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> live.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11278
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;live.com. IN A
;; ANSWER SECTION:
live.com. 3540 IN A 65.55.206.154
;; Query time: 2 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Aug 12 06:56:53 2010
;; MSG SIZE rcvd: 42
By default the Dig command is using the resolving DNS servers, i.e the output will be cached information. To bypass this and get accurate you must dig to the nameserver directly,
dig @ns1.msft.net live.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @ns1.msft.net live.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13389
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;live.com. IN A
;; ANSWER SECTION:
live.com. 3600 IN A 65.55.206.154
;; Query time: 54 msec
;; SERVER: 65.55.37.62#53(65.55.37.62)
;; WHEN: Thu Aug 12 06:58:32 2010
;; MSG SIZE rcvd: 42
Dig command is very useful when verifying the whois information, note that the international domains do not use whois. The most common misunderstandings are that the domain name server (DNS) does not use whois, but whois information is simply a database related to registration so there may be errors between the whois database and the root suffix nameservers that register the domain nameservers.
For understanding dig command, we will first view the root nameservers:
dig
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>>
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45285
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 14435 IN NS g.root-servers.net.
. 14435 IN NS c.root-servers.net.
. 14435 IN NS k.root-servers.net.
. 14435 IN NS h.root-servers.net.
. 14435 IN NS a.root-servers.net.
. 14435 IN NS d.root-servers.net.
. 14435 IN NS j.root-servers.net.
. 14435 IN NS b.root-servers.net.
. 14435 IN NS e.root-servers.net.
. 14435 IN NS f.root-servers.net.
. 14435 IN NS l.root-servers.net.
. 14435 IN NS m.root-servers.net.
. 14435 IN NS i.root-servers.net.
;; Query time: 2 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Aug 12 06:59:55 2010
;; MSG SIZE rcvd: 228
Root nameservers store only the information of the root suffix nameservers such as .com and .net. Here we will use live.us as an example of reverse tracing the nameservers. First we will locate the root suffix nameservers for .us,
dig us NS
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> us NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8423
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;us. IN NS
;; ANSWER SECTION:
us. 11776 IN NS a.cctld.us.
us. 11776 IN NS k.cctld.us.
us. 11776 IN NS j.cctld.us.
us. 11776 IN NS i.cctld.us.
us. 11776 IN NS b.cctld.us.
us. 11776 IN NS c.cctld.us.
;; Query time: 2 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Thu Aug 12 07:02:28 2010
;; MSG SIZE rcvd: 122
We will now locate the nameservers for the sub domain of the root suffix live.us by querying the .us nameservers asking specifically for the NS records,
dig @a.cctld.us linux.us NS
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @a.cctld.us linux.us NS
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12220
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;linux.us. IN NS
;; AUTHORITY SECTION:
linux.us. 7200 IN NS NS2.WEBHOST.us.
linux.us. 7200 IN NS NS1.WEBHOST.us.
;; ADDITIONAL SECTION:
NS1.WEBHOST.us. 7200 IN A 75.125.167.210
NS2.WEBHOST.us. 7200 IN A 75.125.167.211
;; Query time: 4 msec
;; SERVER: 156.154.124.70#53(156.154.124.70)
;; WHEN: Thu Aug 12 07:03:59 2010
;; MSG SIZE rcvd: 102
This would be the information for how live.us is registered with the .us domain registrar.
You might also note that live.us is registered to the WEBHOST.us nameservers which is a separate domain on a different set of root suffix nameservers. While we will skip this step for now, it would be correct to start the process from the beginning to validate theWEBHOST.us nameservers by locating the .us nameservers and then querying them for the nameservers for WEBHOST.us.
Now we can test the domain from the nameservers, but this time we want the full SOA record information:
dig @ns1.webhost.us linux.us SOA
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @ns1.webhost.us linux.us SOA
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13898
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;linux.us. IN SOA
;; ANSWER SECTION:
linux.us. 14400 IN SOA ns209.edns1.net. root.svr105.edns1.com. 2008100801 14400 7200 3600000 86400
;; AUTHORITY SECTION:
linux.us. 86400 IN NS ns209.edns1.net.
linux.us. 86400 IN NS ns210.edns1.net.
;; Query time: 305 msec
;; SERVER: 75.125.167.210#53(75.125.167.210)
;; WHEN: Thu Aug 12 07:05:44 2010
;; MSG SIZE rcvd: 132
Other common records to test for, we will add the +short switch here to make the output less verbose:
Search for the www A record:
dig +short @ns1.webhost.us www.linux.us A
linux.us.
75.125.167.210
Search for the mail MX record:
dig +short @ns1.webhost.us linux.us MX
0 linux.us.
Search for the SPF record, ironically google.com.br does not have SPF records so will use google.com for testing:
dig +short @ns1.google.com google.com TXT
“v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all”
The search of Domain Key, ironically google.com has not yet implemented this so we will test yahoo.com:
dig +short @ns1.yahoo.com _domainkey.yahoo.com TXT
“t=y\; o=~\; n=http://antispam.yahoo.com/domainkeys”
This happened to get interesting as they have used a CNAME for the selector part of the domain key record:
dig @ns1.yahoo.com myselector._domainkey.yahoo.com TXT
; <<>> DiG 9.2.4 <<>> @ns1.yahoo.com myselector._domainkey.yahoo.com TXT
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61897
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;myselector._domainkey.yahoo.com. IN TXT
;; ANSWER SECTION:
myselector._domainkey.yahoo.com. 7200 IN CNAME rc.yahoo.com.
rc.yahoo.com. 1800 IN CNAME rc.fy.b.yahoo.com.
;; AUTHORITY SECTION:
fy.b.yahoo.com. 300 IN NS yf1.yahoo.com.
fy.b.yahoo.com. 300 IN NS yf2.yahoo.com.
;; ADDITIONAL SECTION:
yf1.yahoo.com. 1800 IN A 68.142.254.15
yf2.yahoo.com. 1800 IN A 68.180.130.15
;; Query time: 1 msec
;; SERVER: 68.180.131.16#53(68.180.131.16)
;; WHEN: Wed Feb 25 17:43:15 2009
;; MSG SIZE rcvd: 156
Tracing the path using dig command
We commonly use the command traceroute to watch how the connection establishing from one IP to another IP (point A to point B). You can do a similar thing with dig +trace option.
dig google.com +trace
The result will show you root name servers, then to the servers responsible for all the *.com domains, and it finally points to the name servers responsible for google.com.
If you require help, contact SupportPRO Server Admin
Find DNS
