This is Part 3 of 4 in my series of posts on some of the simple utilities one can use to test networking and DNS configurations. This post will concentrate on using the utility dig to perform simple DNS server queries to ensure that your hostnames are resolving the way you expect them to.
Dig stands for domain information groper and is included in most Linux distributions nowadays (and probably most other Unix variants too). If you’re a windows user, you’ll have to download the dig program. One such site I’ve found for this program is http://pigtail.net/LRP/dig/
Much like nslookup, dig performs DNS lookups and displays the results from the queried name server. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Dig tends to display its results in a format that DNS administrators recognize which resembles the setup for BIND. Other lookup tools tend to have less functionality than dig.
The most common things I use dig for are to:
- Lookup the IP address for a given hostname from a specific server
- Perform a reverse lookup on an IP Address
- Determine the nameservers setup for a domain
- Do a zone transfer of a domain to see all of its configured DNS information
Let’s dive into the examples. The general format for dig commands is:
dig @nameserver.hostname LookupType DomainToLookup
If the first parameter (@nameserver.hostname) is not specified, the default name server your computer uses will be used.
The second parameter LookupType specifies what type of lookup to do. It can be values such as ANY, A, MX, SIG, etc. If this parameter is not specified, dig defaults to looking up A records.
The third parameter is the domain or hostname that we want to lookup information on. It is required. I will go through several examples below.
Simplest Form of Dig Usage
At its simplest level, to lookup what IP timarcher.com resolves to, I show the following command and its associated output:
dig timarcher.com
And the output is:
; <<>> DiG 9.2.4 <<>> timarcher.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49424 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;timarcher.com. IN A ;; ANSWER SECTION: timarcher.com. 300 IN A 24.14.81.77 ;; Query time: 76 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 7 11:42:23 2007 ;; MSG SIZE rcvd: 47
If I want to use a different name server other than your computer’s default to lookup this info, you use a command like the one below, first specifying the name server to use prefixed with the @ symbol:
dig @ns1.everydns.net timarcher.com
This tells me to lookup what timarcher.com resolves to by using the name server ns1.everydns.net. The output looks like:
; <<>> DiG 9.2.4 <<>> @ns1.everydns.net timarcher.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8365 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;timarcher.com. IN A ;; ANSWER SECTION: timarcher.com. 300 IN A 24.14.81.77 ;; AUTHORITY SECTION: timarcher.com. 259200 IN NS ns1.everydns.net. timarcher.com. 259200 IN NS ns2.everydns.net. timarcher.com. 259200 IN NS ns3.everydns.net. timarcher.com. 259200 IN NS ns4.everydns.net. ;; ADDITIONAL SECTION: ns1.everydns.net. 120 IN A 209.131.97.97 ns2.everydns.net. 120 IN A 204.152.184.150 ns3.everydns.net. 86400 IN A 208.96.6.134 ns4.everydns.net. 120 IN A 64.158.219.3 ;; Query time: 73 msec ;; SERVER: 209.131.97.97#53(ns1.everydns.net) ;; WHEN: Sat Apr 7 11:43:02 2007 ;; MSG SIZE rcvd: 195
Use Dig To Determine Mail Exchangers (MX) for a Domain
To get the MX records for a domain, we can specify the type parameter. So to get the MX records for the google.com domain, we issue a command like the following:
dig MX google.com
And our results look like:
; <<>> DiG 9.2.4 <<>> MX google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20066 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com. IN MX ;; ANSWER SECTION: google.com. 1426 IN MX 10 smtp2.google.com. google.com. 1426 IN MX 10 smtp3.google.com. google.com. 1426 IN MX 10 smtp4.google.com. google.com. 1426 IN MX 10 smtp1.google.com. ;; ADDITIONAL SECTION: smtp3.google.com. 1430 IN A 64.233.183.25 smtp4.google.com. 1611 IN A 72.14.215.25 smtp1.google.com. 3507 IN A 216.239.57.25 smtp2.google.com. 1454 IN A 64.233.167.25 ;; Query time: 32 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 7 11:44:56 2007 ;; MSG SIZE rcvd: 180
Use Dig to Determine Name Servers for a Domain
We can also determine who the name servers are for the google.com domain. By using the type parameter NS dig will tell us who the name servers are. The command is:
dig NS google.com
And the output looks like:
; <<>> DiG 9.2.4 <<>> NS google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2444 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com. IN NS ;; ANSWER SECTION: google.com. 233655 IN NS ns1.google.com. google.com. 233655 IN NS ns2.google.com. google.com. 233655 IN NS ns3.google.com. google.com. 233655 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns2.google.com. 345562 IN A 216.239.34.10 ns3.google.com. 345562 IN A 216.239.36.10 ns4.google.com. 345562 IN A 216.239.38.10 ns1.google.com. 345562 IN A 216.239.32.10 ;; Query time: 22 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 7 11:45:55 2007 ;; MSG SIZE rcvd: 164
Use Dig To Do A Reverse Lookup on an IP Address
To determine what hostname an IP address resolves to, we use the -x option to dig. So to lookup what the IP address 216.239.34.10 resolves to, we run the following command:
dig -x 216.239.34.10
And out output looks like the output below, telling us that the IP address if for the hostname ns2.google.com.
; <<>> DiG 9.2.4 <<>> -x 216.239.34.10 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16127 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;10.34.239.216.in-addr.arpa. IN PTR ;; ANSWER SECTION: 10.34.239.216.in-addr.arpa. 86293 IN PTR ns2.google.com. ;; Query time: 5 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Apr 7 11:51:04 2007 ;; MSG SIZE rcvd: 72
Use Dig to Request a Zone Transfer
The last, and perhaps my favorite, thing to use dig for is to request a zone transfer from a specific name server. Many name servers don’t allow this due to their security setup, but if you manage a DNS server you can give yourself privileges to do this. Doing a zone transfer with dig will essentially let you see the entire DNS configuration in the specified DNS server.
To do a zone transfer, we need to specify the name server to do the transfer from (which must be a name server that has authority for the domain), we specify the domain to do the transfer for, and lastly we specify the axfr option. The command looks something like:
dig @usfns.stfrancis.edu stfrancis.edu axfr
This command says to request a zone transfer from usfns.stfrancis.edu for the domain stfrancis.edu.
The output looks something like the output below detailing the DNS setup for a domain.
; <<>> DiG 9.2.4 <<>> @usfns.stfrancis.edu stfrancis.edu axfr ;; global options: printcmd stfrancis.edu. 3600 IN SOA usfns.stfrancis.edu. postmaster.stfrancis.edu. 20011074 3600 600 86400 3600 stfrancis.edu. 3600 IN A 208.44.247.103 stfrancis.edu. 3600 IN NS usfns.stfrancis.edu. stfrancis.edu. 3600 IN NS resolver.qwest.net. stfrancis.edu. 3600 IN NS dca-sns-01.inet.qwest.net. stfrancis.edu. 3600 IN MX 10 usfgwadm.stfrancis.edu. admissions.stfrancis.edu. 3600 IN A 208.44.247.103 alb1.stfrancis.edu. 3600 IN A 206.206.105.83 albbdrmgr.stfrancis.edu. 3600 IN A 206.206.105.82 alumni.stfrancis.edu. 3600 IN A 208.44.247.103 ariel.stfrancis.edu. 3600 IN A 208.44.247.119 auction.stfrancis.edu. 3600 IN A 209.208.119.195 bannerpr.stfrancis.edu. 3600 IN A 208.44.247.117 bannerweb.stfrancis.edu. 3600 IN CNAME usfbannerweb7.stfrancis.edu. breeze.stfrancis.edu. 3600 IN A 208.44.247.111 clare.stfrancis.edu. 3600 IN A 208.44.247.124 ezproxy.stfrancis.edu. 3600 IN A 208.44.247.116 ikon.stfrancis.edu. 3600 IN A 208.44.247.103 login.stfrancis.edu. 3600 IN A 208.44.247.105 mail.stfrancis.edu. 3600 IN CNAME usfgwadm.stfrancis.edu. myfiles.stfrancis.edu. 3600 IN CNAME usf2.stfrancis.edu. myusf.stfrancis.edu. 3600 IN A 208.44.247.118 online.stfrancis.edu. 3600 IN A 208.44.247.109 onlinetest.stfrancis.edu. 3600 IN A 208.44.247.106 stream.stfrancis.edu. 3600 IN A 208.44.247.112 usf2.stfrancis.edu. 3600 IN A 208.44.247.104 usfapps.stfrancis.edu. 3600 IN A 208.44.247.100 ^Husfas1.stfrancis.edu. 3600 IN A 208.44.247.120 usfbannerpr.stfrancis.edu. 3600 IN A 208.44.247.117 usfbannerte.stfrancis.edu. 3600 IN A 208.44.247.117 usfbannerweb7.stfrancis.edu. 3600 IN A 208.44.247.114 usfbdrmgr.stfrancis.edu. 3600 IN A 208.44.247.101 usfgwadm.stfrancis.edu. 3600 IN A 208.44.247.117 usfgwweb2.stfrancis.edu. 3600 IN A 208.44.247.110 usflib1.stfrancis.edu. 3600 IN A 208.44.247.115 usfns.stfrancis.edu. 3600 IN A 208.44.247.98 usfonline3.stfrancis.edu. 3600 IN A 208.44.247.107 usfstream.stfrancis.edu. 3600 IN A 208.44.247.113 usfweb.stfrancis.edu. 3600 IN A 208.44.247.102 usfweb1.stfrancis.edu. 3600 IN A 208.44.247.103 usfwebct.stfrancis.edu. 3600 IN A 208.44.247.106 vmail.stfrancis.edu. 3600 IN A 208.44.247.122 www.stfrancis.edu. 3600 IN CNAME usfweb1.stfrancis.edu. stfrancis.edu. 3600 IN SOA usfns.stfrancis.edu. postmaster.stfrancis.edu. 20011074 3600 600 86400 3600 ;; Query time: 2350 msec ;; SERVER: 208.44.247.98#53(usfns.stfrancis.edu) ;; WHEN: Sat Apr 7 11:59:57 2007 ;; XFR size: 44 records
In summary, the dig utility is a fairly powerful, yet basic, utility to determine DNS configurations. Once you get comfortable with using the basic dig command line options, I suggest you read the dig man page for more details on additional things you can do.
The next post in this series will concentrate on using whois to determine the owner of a domain or IP address on the Internet.
del.icio.us
Digg
StumbleUpon
Comments
dig
A great article, being Unix administrator more than 10 years, I always have some issues using dig utilities, but from now on no worries.
Regards
yey