Understanding DNS Response Flags in dig: A Comprehensive Guide to qr, rd, ra, aa, and cd


1 views

When working with DNS queries using the dig command, the response contains important flags that indicate various aspects of the DNS transaction. These flags appear in the comments section of the output and provide crucial information about how the query was processed.

Here are the most frequently encountered flags in dig responses:

;; flags: qr rd ra;
  • qr (Query Response): Indicates whether the message is a query (0) or response (1)
  • rd (Recursion Desired): Set by the resolver to request recursive resolution
  • ra (Recursion Available): Indicates if the server supports recursive queries
  • aa (Authoritative Answer): Means the response came from an authoritative nameserver
  • cd (Checking Disabled): Bypasses DNSSEC validation when set
  • tc (Truncated): Indicates the response was truncated due to size
  • ad (Authenticated Data): DNSSEC validation was successful
  • do (DNSSEC OK): Requests DNSSEC validation

Let's examine some real-world examples of these flags in action:

$ dig example.com +noall +comments
;; flags: qr rd ra;

$ dig @8.8.8.8 example.com +noall +comments
;; flags: qr rd ra ad;

$ dig +cdflag example.com +noall +comments
;; flags: qr rd ra cd;

Certain combinations of flags indicate specific DNS behaviors:

;; flags: qr aa rd ra;  # Authoritative response with recursion
;; flags: qr rd;        # Non-recursive query
;; flags: qr aa;        # Authoritative non-recursive response

These flags can help diagnose DNS issues:

$ dig +trace example.com | grep "flags"
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The progression of flags during a trace shows the DNS resolution path from root to authoritative servers.

Understanding these DNS response flags is essential for network troubleshooting and DNS server configuration. They provide immediate insight into how a query was processed and what capabilities the responding server supports.


When working with the dig command for DNS troubleshooting, the response flags provide crucial information about the DNS query/response process. These flags appear in the header section of the dig output:

$ dig example.com +noall +comments

; <<>> DiG 9.8.3-P1 <<>> example.com +noall +comments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29045
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Here's the complete enumeration of possible flags in a dig response:

  • qr (Query Response) - Indicates whether the message is a query (0) or response (1)
  • aa (Authoritative Answer) - The response is authoritative for the domain
  • tc (Truncated) - The message was truncated due to size limitations
  • rd (Recursion Desired) - The client requested recursive resolution
  • ra (Recursion Available) - The server supports recursive queries
  • ad (Authenticated Data) - DNSSEC validation was successful
  • cd (Checking Disabled) - DNSSEC validation was not performed

Here are some common scenarios with their corresponding flag patterns:

# Standard recursive query to a caching resolver
$ dig google.com +noall +comments
;; flags: qr rd ra;

# Authoritative response from a nameserver
$ dig @ns1.google.com google.com +noall +comments
;; flags: qr aa rd;

# DNSSEC-validated response
$ dig +dnssec example.com +noall +comments
;; flags: qr rd ra ad;

When analyzing DNS issues, certain flag combinations are particularly meaningful:

  • qr aa - The response came directly from an authoritative server
  • qr rd ra - The query was resolved recursively by a caching resolver
  • qr tc - The response was truncated (may need TCP fallback)
  • qr ad - DNSSEC validation succeeded

For debugging complex DNS issues, you can combine flag analysis with other dig options:

# Check for DNSSEC validation issues
$ dig +cdflag example.com +noall +comments
;; flags: qr rd ra cd;

# Force TCP to avoid truncation
$ dig +tcp example.com +noall +comments

Remember that different DNS server implementations may set these flags differently based on their configuration and capabilities.