Jump to content
  • Announcements

    • dennis

      Welcome to theZAh   06/09/2016

      Enjoy the site and let us know if you find anything not appropriate... silly spammers.

Helpful uses of dig

Recommended Posts

dennis    2

dig is a command-line tool for querying DNS name servers for information about host addresses, mail exchanges, name servers, and related information. 

Understanding the default output


The most typical, simplest query is for a single host. By default, however, dig  is pretty verbose. You probably don’t need all the information in the default output, but it’s probably worth knowing what it is. Below is a simple query.


dig www.hosangit.com

; <<>> DiG 9.8.3-P1 <<>> hosangit.com
;; global options: +cmd

The opening section of dig’s output tells us a little about itself (version 9.8.3) and the global options that are set (in this case, cmd). This part of the output can be quelled by using the +nocmd  option, but only if it’s the very first argument on the command line (even preceeding the host you’re querying).



;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43071
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

Here, dig tells us some technical details about the answer received from the DNS server. This section of the output can be toggled using the +comments  option—but beware that disabling the comments also turns off many section headers.



;hosangit.com. IN A

In the question section, dig reminds us of our query. The default query is for an Internet address (A). You can turn this output on or off using the +question  option.



hosangit.com. 14399 IN A

Finally, we get our answer: the address of hosangit.com  is I don’t know why you’d ever want to turn off the answer, but you can toggle this section of the output using the +answer  option.



hosangit.com.                2351    IN      NS      ns-int.thezah.org.
hosangit.com.                2351    IN      NS      ns1.gearcrushers.com.
hosangit.com.                2351    IN      NS      ns-ext.thezah.org.

The authority section tells us what DNS servers can provide an authoritative answer to our query. In this example, isc.org  has three name servers. You can toggle this section of the output using the +authority  option.



ns1.gearcrushers.com.           171551  IN      A
ns-int.thezah.org.         2351    IN      A
ns-int.thezah.org.         2351    IN      AAAA    2001:4f8:0:2::19

The additional section typically includes the IP addresses of the DNS servers listed in the authority section. This section of the output can be toggled with the +additional  option.



;; Query time: 2046 msec
;; WHEN: Fri Aug 27 08:22:26 2004
;; MSG SIZE  rcvd: 173

The final section of the default output contains statistics about the query; it can be toggled with the +stats  option.

What can I discover?


dig will let you perform any valid DNS query, the most common of which are
A    (the IP address)
TXT  (text annotations)
MX   (mail exchanges)
NS   (name servers)


# get the address(es) for google.com


dig google.com A +noall +answer



# get a list of google's mail servers


dig google.com MX +noall +answer



# get a list of DNS servers authoritative for google.com


dig google.com NS +noall +answer



# get all of the above


dig google.com ANY +noall +answer


You can also poll for a host’s IPv6 address using the AAAA  option.


dig www.isc.org AAAA +short


If the domain you want to query allows DNS transfers, you can get those, too. The reality of life on the Internet, however, is that very few domains allow unrestricted transfers these days.


dig hosangit.com AXFR


How do I …


When all you want is a quick answer, the +short  option is your friend:


$ dig www.isc.org +short

Note that a short answer is different from only an answer. The way to get a detailed answer, but without any auxiliary information, is to turn off all the results (+noall) and then turn on only those sections you want.


Here’s a short answer followed by only an answer; the latter includes all the configuration information, including time-to-live (TTL) data, displayed in a format compatible with BIND configuration files.


$ dig fsf.org mx +short

20 mx20.gnu.org.

30 mx30.gnu.org.

10 mx10.gnu.org.


$ dig +nocmd fsf.org mx +noall +answer

fsf.org.                3583    IN      MX      30 mx30.gnu.org.

fsf.org.                3583    IN      MX      10 mx10.gnu.org.

fsf.org.                3583    IN      MX      20 mx20.gnu.org.

According to its man page, the +multiline  option will give you an answer with “the SOA records in a verbose multi-line format with human-readable comments.” In general, the answers retrieved using the +multiline  option will appear more like BIND config files than they will without it.


$ dig +nocmd ogi.edu any +multiline +noall +answer

ogi.edu.   14267 IN A

ogi.edu.   14267 IN MX 5 cse.ogi.edu.

ogi.edu.   14267 IN MX 15 hermes.admin.ogi.edu.

ogi.edu.   14267 IN SOA zeal.admin.ogi.edu. hostmaster.admin.ogi.edu. (

                   200408230  ; serial

                   14400      ; refresh (4 hours)

                   900        ; retry (15 minutes)

                   3600000    ; expire (5 weeks 6 days 16 hours)

                   14400      ; minimum (4 hours)


ogi.edu.   14267 IN NS zeal.admin.ogi.edu.

ogi.edu.   14267 IN NS cse.ogi.edu.

ogi.edu.   14267 IN NS fork.admin.ogi.edu.

Use the -x  option to lookup the main hostname associated with an IP address.


dig -x +short mx-1.isc.org.

In a loop, this is a slick way to map the names in a given subnet:




for n in $(seq 1 254); do


  echo -e "${ADDR}t$(dig -x ${ADDR} +short)"


Just specify it on the command line:


dig @ns1.google.com www.google.com

The host utility will automatically use the search  list in your /etc/resolv.conf  file.


$ host www

www.madboa.com has address

By default, however, dig doesn’t—which may produce some unexpected results. If you want to use local hostnames instead of fully qualified domain names, use the +search  option.


dig www +search

If you want to look up a large number of hostnames, you can put them in a file (one name per line) and use the -f  option to query each one in turn.


# do full lookups for a number of hostnames

dig -f /path/to/host-list.txt


# the same, with more focused output

dig -f /path/to/host-list.txt +noall +answer

As far as I can tell, dig versions up to and including 9.2.3 are unable to do reverse lookups using the -f  option.


Verifying DNS mappings


An improperly configured DNS setup can be really annoying. You want to make sure that your mappings work both ways:


Each hostname should resolve to an address, and that address ought to resolve back to the proper hostname.

If an address on your subnet(s) has been assigned a reverse pointer to a hostname, that hostname ought to point back to the original address.

There are exceptions to those two rules, of course. A CNAME will resolve to another hostname first, and only then to an address. Sometimes multiple hostnames will point to the same address, but that address will have only one reverse pointer.


Still, it’s good to know that your basic mappings work as expected.


You can script such a test if you build a file containing your known hostnames. The example script below is pretty simple; it will break if fed a CNAME, and it’ll report a failure somewhere if multiple hostnames point to the same address. Let’s assume the file containing your hostnames is named named-hosts.




# test DNS forward- and reverse-mapping



# edit this variable to reflect local class C subnet(s)

NETS="192.168.1 192.168.2"


# Test name to address to name validity


echo -e "tname -> address -> name"

echo '----------------------------------'

while read H; do

  ADDR=$(dig $H +short)

  if test -n "$ADDR"; then

    HOST=$(dig -x $ADDR +short)

    if test "$H" = "$HOST"; then

      echo -e "okt$H -> $ADDR -> $HOST"

    elif test -n "$HOST"; then

      echo -e "failt$H -> $ADDR -> $HOST"


      echo -e "failt$H -> $ADDR -> [unassigned]"



    echo -e "failt$H -> [unassigned]"


done < named-hosts


# Test address to name to address validity


echo -e "taddress -> name -> address"

echo '-------------------------------------'

for NET in $NETS; do

  for n in $(seq 1 254); do


    HOST=$(dig -x $A +short)

    if test -n "$HOST"; then

      ADDR=$(dig $HOST +short)

      if test "$A" = "$ADDR"; then

        echo -e "okt$A -> $HOST -> $ADDR"

      elif test -n "$ADDR"; then

        echo -e "failt$A -> $HOST -> $ADDR"


        echo -e "failt$A -> $HOST -> [unassigned]"





dig fun


Roll your own named.root  file

Any DNS server connected to the Internet is likely to have a copy of the InterNIC’s named.root  file that lists the root name servers for the entire Internet. You can always download that file in the boring way from the InterNIC’s ftp server. Or, in a true build-it-yourself fashion, you can build it with dig.


# compare with ftp://ftp.internic.net/domain/named.root

dig +nocmd . NS +noall +answer +additional

Your TTL values might be a little on the short side, but otherwise, it’s as up-to-date a list as you’ll find!


Tracing dig’s path. Perhaps you’re a devotee of traceroute and like to watch how to get from point A to point B. You can do a similar thing with dig’s +trace  option.


dig gentoo.de +trace

You’ll see dig head to the root name servers, then to the servers responsible for all the *.de domains, and finally to the name servers responsible for gentoo.de.


Grabbing SOA information. As a DNS administrator, I sometimes make changes and want to see if any of my name servers are still pushing the old data. The +nssearch  provides a clear accounting of your public servers.

# the unvarnished truth

dig cse.ogi.edu +nssearch


# the same, displaying only serial number and hostname

dig cse.ogi.edu +nssearch | cut -d' ' -f4,11

Interpreting TTL numbers


I love Google for many reasons, one of which is that it provides referrer strings in my web logs that make it easy to figure out what sort of queries lead people to pages on this site.


Somewhat unexpectedly, I’ve seen a lot of queries asking for information about TTL (time-to-live) numbers. I would have never guessed that TTL would be a topic of interest, but you learn something new every day. So, by popular demand, here’s a brief intro to TTL.


If you ask your local DNS server for an Internet address, the server figures out where to find an authoritative answer and then asks for it. Once the server receives an answer, it will keep the answer in a local cache so that if you ask for the same address again a short time later, it can give you the answer quickly rather than searching the Internet for it all over again.


When domain administrators configure their DNS records, they decide how long the records should remain in remote caches. This is the TTL number (usually expressed in number of seconds).


Typically, a remote server will only cache those records for the length of time specified by the TTL. After that, the remote server will flush its local cache and ask again for an authoritative answer.


When you use dig to query a DNS server concerning a certain record, the server will tell dig the time (in seconds) that record will remain in cache.


For example, as of this writing, the TTL for the MX records for the gmail.com  domain is 300 seconds. The gmail.com  admins are asking that remote servers cache their MX records for no more than five minutes. So when you first ask for that record set, dig will report a TTL of 300.


$ dig +nocmd gmail.com MX +noall +answer

gmail.com.        300     IN      MX      20 gsmtp57.google.com.

gmail.com.        300     IN      MX      10 gsmtp171.google.com.

If you ask a few seconds later, you’ll see the TTL number reduced by approximately the number of seconds you waited to ask again.


$ dig +nocmd gmail.com MX +noall +answer

gmail.com.        280     IN      MX      10 gsmtp171.google.com.

gmail.com.        280     IN      MX      20 gsmtp57.google.com.

If your timing is good, you can catch the record at the very end of its life.


$ dig +nocmd gmail.com MX +noall +answer

gmail.com.        1       IN      MX      10 gsmtp171.google.com.

gmail.com.        1       IN      MX      20 gsmtp57.google.com.

After that, the DNS server you’re querying will “forget” the answer to that question, so the whole cycle will start over again (in this example, at 300 seconds) the next time you perform that query.

Share this post

Link to post
Share on other sites
dennis    2

Here is a great way to query a list of domains and export the domain, flags and authority servers into a csv file.


add all domains (one on each line) in a text file domains.txt


download the attached awk script (note you'll have to change the attached awkdigscript.txt to digscript.awk)



download the attached ksh script (note you'll have to change the attached kshdigscript.txt to digscript.ksh)



Of course make both scripts executable (chmod 755 digscript.awk     chmod 755 digscript.ksh)



./digscript.ksh domains.txt

Share this post

Link to post
Share on other sites
dennis    2
Dig Query Options


dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies.


Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string no to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form +keyword=value. The query options are:



Use TCP when querying name servers. The default behaviour is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used.



Use TCP when querying name servers. This alternate syntax to +tcp is provided for backwards compatibility. The "vc" stands for "virtual circuit".



Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed.



Set the search list to contain the single domain somename, as if specified in a domain directive in /etc/resolv.conf, and enable search list processing as if the +search option were given.



Use the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default.



Deprecated, treated as a synonym for +search



Sets the "aa" flag in the query.



A synonym for +aaonly.



Set the AD (authentic data) bit in the query. The AD bit currently has a standard meaning only in responses, not in queries, but the ability to set the bit in the query is provided for completeness.



Set the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.



Display the CLASS when printing the record.



Display the TTL when printing the record.



Toggle the setting of the RD (recursion desired) bit in the query. This bit is set by default, which means dig normally sends recursive queries. Recursion is automatically disabled when the +nssearch or +trace query options are used.



When this option is set, dig attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone.



Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.



toggles the printing of the initial comment in the output identifying the version of dig and the query options that have been applied. This comment is printed by default.



Provide a terse answer. The default is to print the answer in a verbose form.



Show the IP address and port number that supplied the answer when the +short option is enabled. If short form answers are requested, the default is not to show the source address and port number of the server that provided the answer.



Toggle the display of comment lines in the output. The default is to print comments.



This query option toggles the printing of statistics: when the query was made, the size of the reply and so on. The default behaviour is to print the query statistics.



Print the query as it is sent. By default, the query is not printed.



Print the question section of a query when an answer is returned. The default is to print the question section as a comment.



Display the answer section of a reply. The default is to display it.



Display the authority section of a reply. The default is to display it.



Display the additional section of a reply. The default is to display it.



Set or clear all display flags.



Sets the timeout for a query to T seconds. The default time out is 5 seconds. An attempt to set T to less than 1 will result in a query timeout of 1 second being applied.



Sets the number of times to try UDP queries to server to T instead of the default, 3. If T is less than or equal to zero, the number of tries is silently rounded up to 1.



Sets the number of times to retry UDP queries to server to T instead of the default, 2. Unlike +tries, this does not include the initial query.



Set the number of dots that have to appear in name to D for it to be considered absolute. The default value is that defined using the ndots statement in /etc/resolv.conf, or 1 if no ndots statement is present. Names with fewer dots are interpreted as relative names and will be searched for in the domains listed in the search or domain directive in /etc/resolv.conf.



Set the UDP message buffer size advertised using EDNS0 to B bytes. The maximum and minimum sizes of this buffer are 65535 and 0 respectively. Values outside this range are rounded up or down appropriately.



Print records like the SOA records in a verbose multi-line format with human-readable comments. The default is to print each record on a single line, to facilitate machine parsing of the dig output.



Do not try the next server if you receive a SERVFAIL. The default is to not try the next server which is the reverse of normal stub resolver behaviour.



Attempt to display the contents of messages which are malformed. The default is to not display malformed answers.



Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query.



Chase DNSSEC signature chains. Requires dig be compiled with -DDIG_SIGCHASE.



Specifies a file containing trusted keys to be used with +sigchase. Each DNSKEY record must be on its own line.

If not specified dig will look for /etc/trusted-key.key then trusted-key.key in the current directory.

Requires dig be compiled with -DDIG_SIGCHASE.



When chasing DNSSEC signature chains perform a top down validation. Requires dig be compiled with -DDIG_SIGCHASE.

Share this post

Link to post
Share on other sites
dennis    2

DIG response header (Ref:RFC 1035)


QR = Specifies whether this message is a query (0), or a response (1)

OPCODE = A four bit field, only valid values: 0,1,2

Z = Reserved for future use. Must be zero

AA = Authoritative Answer

TC = Truncation (truncated due to length greater than that permitted on the transmission channel)

RD = Recursion Desired (set in a query and copied into the response if recursion is supported)

RA = Recursion Available (if set, denotes recursive query support is available)

AD = Authenticated Data (for DNSSEC only; indicates that the data was authenticated)

CD = Checking Disabled (DNSSEC only; disables checking at the receiving server)

Response code:

0 = NOERR, no error

1 = FORMERR, format error (unable to understand the query)

2 = SERVFAIL, name server problem

3= NXDOMAIN, domain name does not exist

4 = NOTIMPL, not implemented

5 = REFUSED (e.g., refused zone transfer requests)

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now