Interpreting and Analyzing dig output

This blog post explains how to interpret the dig output in various day to day scenarios. 

By default the dig command output only displays the response packet from the DNS server and this is enough 99.9% of the times you are using dig to troubleshoot a DNS issue.

But it is possible to force dig to display the query packet sent to the DNS server as well. Just add +qr option to the command.

Next lets check out the different sections in a dig output. 

Command Section: Displays the dig version and the command which was entered including any options.

Header Section: Displays the Transaction Id, RCODE and Flags from the DNS Headers

Question Section: Displays the DNS query received by the server. The DNS server simply echoes back the received query in the response packet.

Answer Section: Displays the answers to the DNS query. This is the main section. It contains the DNS Resource Records which make up the response from the server. The fields are explained below.

Authority Section: Displays the NS records which show the Name Servers for the domain.

Additional Section: Displays the IPv4 and IPv6 addresses of the Name Servers. Note that the OPT PSEUDOSECTION is counted as 1 Additional record. Therefore in the above output the count of additional records in the Header section shows 9 despite only 8 Additional records in the Additional section of the output.

Statistics Section: This section contains some important statistics about the whole query/response transaction like time it took for the response to come back to the client, size of the response etc.

Note that in the earlier outputs the Authority and the Additional sections were missing. This is perfectly normal. The presence or absence of these sections depends on a setting found in most DNS servers - On BIND this setting is called minimal-response. If set to Yes the resolver will not send the Authority and Additional section to the end client. The end client does not need these sections per se in the response - it is mainly interested to see the Answer section. These sections are important to the resolver when it receives a response from the Root and TLD Name Servers during the recursion process as these sections contain the NS records and Glue records from the referral. Below image shows a query for f5.com sent to com TLD's Name Server which returns a referral to the Authoritative Name Servers for f5.com along with their IPs in the Additional section since the domain is using White Label Name Servers.

 Most Authoritative Name Servers also send the NS records for the domain they are Authoritative for in the Authority section when replying to any regular query such as A, CNAME, MX etc. They also send the IPs of the Name Servers in the Additional section if the Name Servers are White Label AKA Branded AKA Vanity. The below image shows a query sent to the Authoritative Name Server of cisco.com for the A record of cisco.com. The Authoritative Name returned the NS records and also the IPs of the branded Name Servers in the Authority and the Additional sections respectively along with the A record for cisco.com.

Breaking down the fields from the Answer section:

1. The domain name

2. TTL (Time To Live) which indicates for how long this answer can be cached by resolvers or by end clients.

3. Class which specifies the protocol family or namespace that the record belongs to. In almost all everyday DNS use, you’ll see IN as the class which stands for Internet. All normal DNS lookups for A, AAAA, PTR, CNAME, TXT, MX, SRV and other well known record types on the Internet and also in the LAN environment use this class. There are other classes too but are used rarely - they have historical and experimental use cases. For example the below image shows how the CH class can be used to get the version of the DNS software running on a DNS server (needs to be supported and configured on the DNS server beforehand)

4. Type of Record

5. The record value or in other words the answer to the DNS query.

The question section fields are similar - they describe the query. In this example the query is for the A record of google.com. There is no TTL or Record value which makes sense since those fields are only relevant in a DNS response.

 The below image explains the information found in the Header and the Statistics sections:

The Query time in the Statistics section along with the TTL in the Answer section can be used to make an informed decision on whether the response came from the Resolver's cache or whether the Resolver had to get the Response from the Authoritative Name Servers.

   - The Query Time if much higher than the latency between the client and the Resolver and the TTL showing round numbers like 180 second, 300 seconds, 600 seconds etc. (above image) indicate that the Resolver had to fetch the answer. (The latency from my client to Resolver is ~5 milliseconds)

   - The Query Time if more or less equal to the latency between the client and the Resolver and a random TTL number (image below) indicates that the answer came from the Resolver's cache

Now lets check out a few different scenarios:

1. The aa flag in a response: This flag will appear in the response when querying an Authoritative Name Server directly. It indicates that the response is Authoritative or in other words it comes directly from the Authoritative Name Server for the domain. If a resolver gets the response for you by querying the Authoritative Name Server it won't add this flag in the response since it is not Authoritative for the domain. The response from a resolver is considered a Non Authoritative Response. In this example I queried the Authoritative Name Server for cisco directly and hence the aa flag in the response.

2. The tc flag in the response and the significance of the OPT PSUEDOSECTION: The presence of this section and the EDNS record inside it indicates that the client supports EDNS. This allows for responses over 512 bytes over UDP. In the below image the response size is 689 bytes but it was still received over UDP.

In the below image the query was sent with the +noedns option which can be used to simulate a client which does not support EDNS (Note that there is no OPT PSUEDOSECTION). The response from the server was truncated as indicated by the line ";; Truncated, retrying in TCP mode.". If you check this DNS response packet on a pcap the tc flag would be set. On seeing the tc flag the client retried the same query over TCP and gets the full response (Note that the protocol shows as TCP in the Statistics section)

To interpret the EDNS UDP buffer size supported by the client and by the server use the +qr flag as shown in the below image. The 1st part of the output shows the query. I deliberately set the UDP buffer size to 1000 with the +bufsize option to show that the client set the UDP buffer size to 1000 in the EDNS section. The 2nd part of the output shows the response and the ENDS section shows a buffer size of 1232 - this indicates the max size of a UDP response supported by the server. If you don't add the +qr option then only the EDNS buffer size from the response is shown in the output. If the response exceeds either the clients supported buffer size (which is visible with the +qr option) or the servers max UDP response size then the response will be truncated and the client will need to switch to TCP to get the complete response. On a side note the default buffer size on latest dig versions and latest versions of BIND is set to 1232 (older BIND versions used to set 4096). This is so that the UDP response does not get fragmented since the standard MTU on the Internet is 1500 - fragmented UDP DNS response packets sometimes get blocked by older Firewalls and hence it was decided to keep the UDP response limited to 1232 bytes on BIND (Other DNS servers may have other defaults)

 3.  The REFUSED RCODE: This RCODE indicates that the DNS Server refused to answer the query. If a resolver returns this response the most likely reason is that it is not configured to provide recursive services to just about any client IP. It has ACLs configured specifying the client IP ranges which can send recursive queries. On the other hand if the query was sent to an Authoritative Name Server like in the image below it means that this Name Server is not Authoritative for the domain and it also does not provide recursion services (note the absence of the ra flag)

4. The SERVFAIL RCODE: This RCODE indicates that the resolver could not get the answer for you. It does not necessarily indicate a configuration issue with the resolver but it definitely could be. There can be several reasons for this RCODE:

1. The Resolver could not reach the Root/TLD/Authoritative servers on the Internet for any reason such as Firewalls/Routing issues etc.
2. The Resolver received an invalid response from any of the Servers it is reaching out to during the recursion process like in the image below the Resolver received a REFUSED status code from the Authoritative Servers for x7networks.com as indicated in the OPT PSUEDOSECTION section of the output. Google's 8.8.8.8 and CloudFare's 1.1.1.1 very recently started adding this information to provide a hint as to why the Resolver is returning a SERVFAIL. The REFUSED status indicates something wrong with the Authoritative Name Servers of the domain - either they are incorrect or not ready.
3. The Resolver is configured to perform DNSSEC validation, the domain being looked up is DNSSEC enabled and the DNSSEC validation failed for some reason for example the DS record is out of sync with the zone's KSK record.
4. The resolver is facing some configuration related restrictions for example the lookup needs a lot of Iterative Queries because the domain has a lot of labels (delegations) like www.hr.staging.sydney.ultimatenetworkwarrior.com or there are too many levels of CNAME chaining. Resolvers like BIND for example have settings like max-recursion-depth, max-recursion-queries and max-query-restarts which may get exceeded and hence the Resolver returns a SERVFAIL to the client.