Did you come here from a search engine? Click here for my main page.

What it does

dig (also apparently known as "domain internet groper") is a utility that can talk directly to name servers (DNS hosts) in order to gather detailed DNS-related information about a network host or domain of interest.

dig output tends to be rather verbose and cryptic; using it is a bit like posing a question to your office alpha-geek and getting a ten-minute answer in return (with the ten seconds of info you want buried somewhere in the noise). For this reason, it's often easier to get the information you want using other tools like host or nslookup. However, there are a few circumstances in which dig comes in very handy. These include:

How to get it

dig is one of the basic utilities associated with the Berkeley Internet Name Domain (BIND), by far the most common DNS server software in use today. If you use a Unix-like system (such as Linux, BSD, Solaris, Apple Mac OS X / Darwin, etc.), you more than likely have dig available on your system already. You need only run a terminal program (or otherwise get access to command-line operation) and then type the command as shown below. Use the Unix whereis command (i.e., "whereis dig") to find dig if it isn't on your normal paths.

If you are using some other operating system on your computer (in particular, MS Windows, or Mac OS 9 and earlier), you may not have dig installed. In this case, you can either find a port of the dig command for your particluar system, or else (if you don't like command lines) use one of the GUI-based or web-based alternatives described at the bottom of this page.

How to use it

The dig command comes in a few different flavors, and the manner in which you specify the arguments may differ from one version to another. For purposes of this discussion, we'll use the version of dig provided with Mac OS X / Darwin (dig 9.2.2, associated with BIND 9, to be specific).

Here's the basic syntax for the dig queries we'll be concerned with here:

Note that the [name] argument will take on different forms depending upon the type of query; it might have to be a bare domain name in some cases, while it might have to be a host name in others; in the case of the PTR lookup, [name] will be an IP address rendered in a special form.

The query types we'll be looking at include:

A
IP address(es) associated with [name] (must be a host name or alias).
name(s) of the mail exchanger hosts for [name] (must be a bare domain name)
name(s) of the authoritative name server(s) for [name] (must be a bare domain name).
 CNAME 
"canonical' name for [name] (must be a host name or alias).
the host name formally associated with [name], where [name] is the IP address (in an altered form).
all information that the DNS server has on [name] (may be a domain name, host name, or alias)

Type "A" lookup (IP address)

The type-A query returns the IP address(es) associated with a host name or alias.

By default, dig will perform the type-A query unless you specify another type. Here's a simple example:

alu-g4pb:~ rconner$ dig rickconner.net

; <<>> DiG 9.2.2 <<>> rickconner.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5440
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;rickconner.net.             IN    A

;; ANSWER SECTION:
rickconner.net.      7910    IN    A    209.198.131.19


;; AUTHORITY SECTION:
rickconner.net.      7910    IN    NS   ns1.prismnet.com.
rickconner.net.      7910    IN    NS   ns2.prismnet.com.

;; ADDITIONAL SECTION:
ns1.prismnet.com.    145564  IN    A    209.198.128.11
ns2.prismnet.com.    145564  IN    A    209.198.128.27

;; Query time: 105 msec
;; SERVER: 199.45.32.43#53(199.45.32.43)
;; WHEN: Tue Jan 24 22:26:16 2006
;; MSG SIZE rcvd: 128

There are two things to note in this example:

As you can see, the printout from dig is rather verbose and full of strange gobbledegook. For our purposes, we are interested only in the data under the 'ANSWER SECTION' heading. If for some reason DNS did not have the information we were looking for, we would get the same printout, only without an answer section. When working with dig, always be sure that you get an answer section in the output, and take your information from there.

Some host name aliases are actually mapped to more than one address. We can use dig to find this out:

alu-g4pb:~ rconner$ dig a www.yahoo.com

[...bla bla bla...]

;; ANSWER SECTION:
www.yahoo.com.         89   IN   CNAME   www.yahoo.akadns.net.
www.yahoo.akadns.net.  27   IN   A       68.142.226.42
www.yahoo.akadns.net.  27   IN   A       68.142.226.48
www.yahoo.akadns.net.  27   IN   A       68.142.226.50
www.yahoo.akadns.net.  27   IN   A       68.142.226.51
www.yahoo.akadns.net.  27   IN   A       68.142.226.54
www.yahoo.akadns.net.  27   IN   A       68.142.226.34
www.yahoo.akadns.net.  27   IN   A       68.142.226.38
www.yahoo.akadns.net.  27   IN   A       68.142.226.41



[...remainder snipped...]

What this tells us is that www.yahoo.com points to the canonical name (CNAME) www.yahoo.akadns.net (according to the yellow line) which in turn points to eight separate IP addresses (in the blue lines). Typically, only high-volume services like Yahoo require such a complex setup; most websites get by with a single IP address.

On the other hand, some spammers use so-called zombies or reverse web proxies to make their websites appear to be hosted on several IP addresses at once. They will then change these records very rapidly in a sort of internet version of Hide And Seek. You can sniff out this behavior using dig a:

$ dig a bedwoman.cn

; <<>> DiG 9.3.4 <<>> a bedwoman.cn
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49659
;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bedwoman.cn. IN A

;; ANSWER SECTION:
bedwoman.cn. 120 IN A 87.228.67.202
bedwoman.cn. 120 IN A 88.73.193.69
bedwoman.cn. 120 IN A 88.134.41.48
bedwoman.cn. 120 IN A 88.134.58.168
bedwoman.cn. 120 IN A 88.134.60.15
bedwoman.cn. 120 IN A 89.169.110.47
bedwoman.cn. 120 IN A 91.66.72.74
bedwoman.cn. 120 IN A 91.66.88.56
bedwoman.cn. 120 IN A 99.248.119.110
bedwoman.cn. 120 IN A 218.173.163.34
bedwoman.cn. 120 IN A 62.143.208.237
bedwoman.cn. 120 IN A 62.182.74.196
bedwoman.cn. 120 IN A 62.182.77.225
bedwoman.cn. 120 IN A 77.238.231.111
bedwoman.cn. 120 IN A 78.94.127.166
bedwoman.cn. 120 IN A 79.207.167.9
bedwoman.cn. 120 IN A 80.217.188.185
bedwoman.cn. 120 IN A 84.234.130.136
bedwoman.cn. 120 IN A 85.177.35.18
bedwoman.cn. 120 IN A 85.216.50.215

Here, we see that bedwoman.cn actually points to no fewer than twenty distinct addresses, located in widely-different blocks belonging to many different providers (no doubt each of these belonging to some subverted zombie computer). You can see that the time-to-live (TTL) of these references (given just after the host name in each line) is only 120 seconds, which is extraordinarily low for a DNS record of any type. This means that the spammers will soon be rewickering their DNS hosts to rotate in a different set of addresses in order to keep investigators off their trail (this sort of thing is also known as a fast-flux botnet).

Type "MX" lookup (mail routing info)

DNS plays a very important role in routing e-mail among internet domains. Specifically, it holds MX ('mail exchanger') records for domains. These records tell you which mail hosts are assigned to accept mail bound for an e-mail address in a given domain.

You can use dig to look up mail exchanger records; they may give you clues as to the nature of a spam domain. Here, you supply a domain name for the MX lookup:

alu-g4pb:~ rconner$ dig mx finance123yourhom.com

[...bla bla bla...]

;; ANSWER SECTION:
finance123yourhom.com. 3600 IN MX 0 smtp.secureserver.net.
finance123yourhom.com. 3600 IN MX 10 mailstore1.secureserver.net.


;; AUTHORITY SECTION:
finance123yourhom.com. 3600 IN NS PARK9.secureserver.net.
finance123yourhom.com. 3600 IN NS PARK10.secureserver.net.

Our answers are found in the light-blue text: smtp.secureserver.net and mailstore1.secureserver.net are the two hosts to which we would have to direct mail addressed to users in the finance123yourhom.com domain. This spam domain is thus getting mail support from secureserver.net (and is also getting DNS support from them, judging by the "AUTHORITY SECTION" below the answer).

Type "NS" lookup (authoritative name servers)

Part of the setup procedures for any internet domain is the specifying of "authoritative" name servers for the domain; these are the name servers that are "officially" responsible for knowing exactly where (on the IP network) all hosts in this domain are located. Most domains will usually have at least two such name servers, for the sake of reliability (if one is down, the other one should still work and can be consulted).

The type-NS dig query will reveal the names (and IP addresses, if available) of the authoritative name servers. For example:

alu-g4pb:~ rconner$ dig ns shinobia.com

[...bla bla bla...]

;; ANSWER SECTION:
shinobia.com. 2419 IN NS e1.lenslessli.com.
shinobia.com. 2419 IN NS e2.lenslessli.com.

;; ADDITIONAL SECTION:
e1.lenslessli.com. 140651 IN A 211.144.147.202
e2.lenslessli.com. 140651 IN A 220.248.227.111

Given that shinobia.com is a spam website, it probably would not surprise you to learn that it's name service at lenslessli.com looks to be crooked: this domain has no default website, it was set up just a month or so previously to my receiving spam related to it, its whois registration data looks suspicious, and the two nameserver addresses (listed in the "additional section") belong to Chinese providers. Not only that, but the spam website itself (shinobia.com) also points to one of these same addresses:

alu-g4pb:~ rconner$ host shinobia.com
shinobia.com has address 211.144.147.202

It's very common in the world of spam hosting for one or more of a spam domain's authoritative name servers to be located at the same IP address as the spam website itself, usually under a different domain name as in this case. Some spammers will try to hide their websites from detection by getting the websites embedded in DNS server caches all around the world, and then actually shutting down the authoritative name service for the sites (thereby making authoritative DNS lookups impossible).

Type "CNAME" lookup (canonical host name)

Normally, a DNS lookup is supposed to give you an IP address when you give it a host name. In some cases, it may give you another host name instead, via the CNAME ("canonical name") mechanism. For example, the operators of www.friendlystore.foo might choose to set up their DNS to have this host name point to the CNAME privatehost99.bigbizhost.foo rather than directly to one or more IP addresses. In other words, CNAMEs are used to redirect DNS queries from one host name to another. There are various reasons why an operator might wish to use CNAMEs, but they don't enter into our discussion here.

We actually saw CNAMEs in action in the Yahoo example further up this page. Since we were making a type-A query, dig actually followed the CNAME redirection and gave us the addresses belonging to the CNAME host, so we got the information we were looking for.

You can use a CNAME query to find out whether a host you seek actually points to a CNAME. Possibly you may find a spam domain set up with a CNAME, but this would be rare. More likely, you would see CNAMEs used by large internet operations:

alu-g4pb:~ rconner$ dig cname www.msn.com

[...bla bla bla...]

;; ANSWER SECTION:
www.msn.com.   223   IN   CNAME   www.msn.com.nsatc.net.

A bit more poking around yields the information that the nsatc.net domain is owned by the internet provider Savvis Communications, which appears to be providing the hosting services for MSN (and other Microsoft services as well).

Because we made a CNAME query, DNS gave us only the CNAME answer and not the addresses belonging to the CNAME host; if we wanted this information, we could run a type-A query on www.msn.com.nsatc.net (or, we could cut out the middleman and just run the type-A query on www.msn.com).

Type "PTR" lookup (reverse DNS lookup)

Normally, DNS is used to resolve a host name or alias into an IP address so that your computer can find the resource you're looking for. However, it's also possible to go in the reverse direction — to find the host name associated with a numeric IP address. This is sometimes called "reverse-resolving" or "reverse DNS."

In order for reverse DNS to work, the IP address must have a pointer or PTR record set up within DNS that will link the address to its default name. We can use dig to find out whether any given IP address has a PTR record set up.

To do a PTR lookup with dig, we must first convert the IP address into a host-name-like construct by reversing the order of the octets (no, I don't know why) and then appending the string ".in-addr.arpa" — for example, given the address 216.109.118.64 we transform this address to 64.118.109.216.in-addr.arpa and then use this with the dig ptr command:

alg4pb:~ rconner$ dig ptr 64.118.109.216.in-addr.arpa

[...bla bla bla...]

;; ANSWER SECTION:
64.118.109.216.in-addr.arpa. 1200 IN PTR p1.www.dcn.yahoo.com.

[...remainder snipped...]

We got our answer in the answer section: p1.www.dcn.yahoo.com. Note that the PTR name may or may not be the same as the CNAME for the host, and that you can have a PTR name without a CNAME.

Type "ANY" query (all info)

If you really like to pick through obscure printouts, you can run an "ANY" query to get dig to tell you all of the information that DNS has for a domain, host name, or alias. For example:

pool-138-88-79-112:~ rconner$ dig any whitehouse.gov

[...bla bla bla...]

;; ANSWER SECTION:
whitehouse.gov.   7200  IN  SOA ep.eop.gov. postmaster.whitehouse.gov.
whitehouse.gov.   7200  IN  A   63.161.169.137
whitehouse.gov.   7200  IN  MX  100 mailhub-wh2.whitehouse.gov.
whitehouse.gov.   7200  IN  NS  ns1-auth.sprintlink.net.
whitehouse.gov.   7200  IN  NS  ns2-auth.sprintlink.net.
whitehouse.gov.   7200  IN  NS  ns3-auth.sprintlink.net.

;; AUTHORITY SECTION:
whitehouse.gov.   7200  IN  NS  ns3-auth.sprintlink.net.
whitehouse.gov.   7200  IN  NS  ns1-auth.sprintlink.net.
whitehouse.gov.   7200  IN  NS  ns2-auth.sprintlink.net.

;; ADDITIONAL SECTION:
mailhub-wh2.whitehouse.gov. 7200   IN   A   63.161.169.140
ns1-auth.sprintlink.net.    22730  IN   A   206.228.179.10
ns2-auth.sprintlink.net     22740  IN   A   144.228.254.10
ns3-auth.sprintlink.net.    23087  IN   A   144.228.255.10

Here, we are given the following records for whitehouse.gov: the SOA (start of authority, the "root" of the DNS zone that includes this domain), the A record (the IP address of whitehouse.gov), the MX record (the mail exchanger for the domain), and NS (the authoritative name servers for the domain). Along the way, we see that there's no CNAME for this host, and that White House uses Sprint as its provider. In case we need them, dig helpfully provides the A records for all of the MX and NS hosts named in the answer section.

Note that you won't necessarily get such a cornucopia of data when you use dig any; if you are interested in a particular DNS record, you will probably have to query it specifically by type.

Alternatives to command-line dig

If you don't have the dig command available on your system, or don't want to use it, you still have several alternatives. There are at least two websites that will be useful:

You might also be able to find GUI-based dig tools for your system from your favorite shareware/freeware depository site.



 Legend:  new window    outside link    tools page  glossary link   


(c) 2003-2008, Richard C. Conner ( )

18133 hits since March 27 2009

Updated: Wed, 11 Jun 2008