Dig

The Domain Information Groper (dig) command line utility is useful for troubleshooting and "debugging" a DNS server setup. This page contains a information and examples on its usage.

To find general information about DNS, check out the glossary and Q&A sections on the DNS wiki page.

References

• man page

Basic usage

This is the basic usage of dig:

dig [@<name-server>] <record-name> [<record-type>] [<options>]

Notes:

• If no name server is specified, dig queries the DNS server it finds in /etc/resolv.conf. If no DNS server is noted there, dig will query localhost.
• The record name is usually a domain name. Note: When you specify a second-level domain the response will not contain any CNAME records, because CNAME record names are fore subdomains.
• If the record type is omitted, dig will look for "A" records. The record type "any" has no longer any practical use as a wildcard, because modern DNS servers will no longer provide any useful information for such a query. This is due to RFC 8482.
• Unless specified otherwise, dig will use UDP (not TCP) for queries.

Output analysis

TODO Show an annotated output example

Simple queries

Get "MX" record information:

dig herzbube.ch mx

Get "A" record information:

dig herzbube.ch
dig herzbube.ch a

Get "SOA" record information. The SOA record points to the primary DNS server of a domain.

dig herzbube.ch soa

Get information from a specific DNS server (e.g. obtained from the SOA record):

dig @anna.ns.cloudflare.com herzbube.ch mx

Note: In this example, dig needs to lookup anna.ns.cloudflare.com first. It will do so behind the scene, by querying one of the DNS servers listed in /etc/resolv.conf.

Options

Only show the "answer" section. First all sections are disabled, then the answer section is re-enabled.

dig herzbube.ch mx +noall +answer

Display the result on multiple lines with human readable comments. This only has an effect on certain record types, such as the SOA record type.

dig herzbube.ch SOA +multiline

Do not display TTL information in the query result:

dig herzbube.ch mx +nottlid

Perform a non-recursive query:

dig herzbube.ch mx +norecurse

Reverse lookups

Reverse lookup an IP address:

dig -x 212.101.18.224

Delegation

To check whom forward or reverse DNS is delegated to:

dig herzbube.ch ns                    # Forward DNS delegation for domain herzbube.ch
dig 224.18.101.212.in-addr.arpa ns    # Reverse DNS delegation for static public IP 212.101.18.224
dig 1.168.192.in-addr.arpa ns         # Reverse DNS delegation for private network 192.168.1.0

Perform iterative queries, starting at the root DNS servers, and display the result of each query. This is useful to see the delegation path from the root DNS servers to the name being looked up. Note that in this use case the queries issued by dig are not recursive.

dig herzbube.ch mx +trace

Troubleshooting

dig returns with SERVFAIL

If dig returns with SERVFAIL error, this means that the DNS server it queried was unable to answer the request due to some internal error. In my case I had the problem when I tried to perform a reverse lookup.

The problem was two-fold:

• I tried to lookup the address 192.168.0.1, but my DNS server was mis-configured in a way so that it didn't know about either of the zones 168.192.in-addr.arpa or 0.168.192.in-addr.arpa
• My DNS server was also not configured to forward the request to some other DNS server
• The end result was that my DNS server could not answer the request, so the response was SERVFAIL

Interestingly enough, when I tried the utility host instead of dig I always received some sort of valid response. The reason for this is that host goes to the next DNS server if it receives a SERVFAIL, so after my own DNS server was unable to answer the request, host happily went on to query my ISP's DNS server (which of course was setup correctly). To prevent this, one can use the -s option:

host -s 192.168.0.1