Understanding DNS Flags & DNSSEC Validation

Updated February 9, 2026

Every DNS response carries a set of flags in its header that tell you how the query was handled and whether the results can be trusted. This guide explains each flag and shows how DNSSEC uses them to protect DNS from tampering.

DNS Response Flags

When you query a domain, the DNS server returns a 16-bit flags field in the response header. Each bit conveys specific information about the response. Here's what each flag means.

AA — Authoritative Answer

The AA flag is set when the response comes directly from the nameserver that is authoritative for the domain — meaning it holds the original, master copy of the zone data rather than a cached copy.

When it's set: You queried the domain's own nameserver (e.g., ns1.example.com for example.com).

When it's not set: The response came from a recursive resolver (like 8.8.8.8) that fetched and cached the answer on your behalf.

TC — Truncated

The TC flag signals that the response was too large to fit in a single UDP packet (traditionally 512 bytes) and was truncated. The client should retry the query over TCP to get the full answer.

When it's set: Large responses — domains with many records, long TXT records (like DKIM keys), or DNSSEC-signed responses with large RRSIG records.

When it's not set: Most queries. Modern resolvers support EDNS0, which extends the UDP payload size to 4096 bytes, making truncation rare.

RD — Recursion Desired

The RD flag is set in the query by the client to ask the server to perform recursive resolution — following the chain from root servers to authoritative servers on the client's behalf.

When it's set: Almost always. Your device sets RD when querying a recursive resolver like 8.8.8.8 or 1.1.1.1.

When it's not set: Queries sent directly to authoritative-only nameservers that don't perform recursion, or when deliberately testing iterative resolution.

RA — Recursion Available

The RA flag is the server's reply to RD — it confirms that the server supports recursive queries.

When it's set: The server is a recursive resolver (Google DNS, Cloudflare DNS, your ISP's resolver).

When it's not set: The server is authoritative-only and does not perform recursion for external clients.

AD — Authenticated Data

The AD flag is the key DNSSEC signal. It means the recursive resolver has cryptographically validated the response using the DNSSEC chain of trust — from the root zone's keys down to the domain's own signatures.

When it's set: The domain uses DNSSEC, the signatures are valid, and the resolver performed validation.

When it's not set: Either the domain doesn't use DNSSEC, or the resolver didn't validate (or validation failed).

CD — Checking Disabled

The CD flag is set in the query to tell the resolver to skip DNSSEC validation and return the response regardless of signature validity.

When it's set: Diagnostic scenarios — you want to see what records exist even if DNSSEC validation fails (e.g., debugging a broken DNSSEC configuration).

When it's not set: Normal operation. You want the resolver to validate signatures and reject tampered responses.

RCODE — Response Code

The RCODE is a 4-bit field (not a single flag) indicating the result status of the query.

DNSSEC — How DNS Gets Authenticated

DNSSEC (Domain Name System Security Extensions) adds a layer of cryptographic authentication to DNS. Without it, DNS responses travel unsigned — any device in the network path could theoretically forge a response and redirect traffic.

How DNSSEC Works

DNSSEC creates a chain of trust that starts at the DNS root zone and extends down to individual domains:

1. Zone signing — The domain owner signs their DNS records with a private key, producing RRSIG (signature) records alongside each record set.
2. DNSKEY records — The domain publishes its public keys as DNSKEY records so resolvers can verify the signatures.
3. DS records — A hash of the domain's key is placed in the parent zone (e.g., .com holds the DS record for example.com), linking the child zone's key to the parent.
4. Chain of trust — This linking continues up to the root zone, whose keys are well-known and pre-configured in resolvers (the "trust anchor").

When a DNSSEC-validating resolver processes a query, it verifies every signature from the root down to the target domain. If all signatures check out, it sets the AD flag in the response. To see this chain of trust in action — including DS and DNSKEY records at each zone level — use our Delegation Trace tool or read the DNS delegation guide.

DNSSEC Status in DNS Kit

DNS Kit shows three DNSSEC states for every lookup:

• DNSSEC Validated (green) — The domain has DNSKEY records and the resolver confirmed the AD flag. This is the strongest assurance: the records are authentic and untampered.
• DNSSEC Enabled (amber) — The domain has published DNSKEY records (signing is configured), but the AD flag was not set. This can happen if the resolver doesn't validate DNSSEC, or if the chain of trust is incomplete.
• No DNSSEC (gray) — No DNSKEY records were found. The domain does not use DNSSEC, so responses are unsigned.

Why DNSSEC Matters

Without DNSSEC, DNS is vulnerable to:

• Cache poisoning — An attacker injects forged records into a resolver's cache, redirecting users to malicious servers.
• DNS spoofing — On-path attackers intercept DNS queries and return fake responses.
• Man-in-the-middle attacks — Redirecting traffic through an attacker's server to intercept credentials or inject malware.

DNSSEC eliminates these attacks by making it cryptographically impossible to forge a valid response without the domain's private signing key.

Reading Flags in Practice

Here's what a typical flag combination tells you:

Summary

DNS flags are small but powerful indicators packed into every response. The AD flag and DNSSEC status are especially important — they tell you whether the DNS records you're looking at can be trusted or whether they could have been tampered with in transit. Understanding these flags helps you diagnose DNS issues faster and assess the security posture of any domain.

For a complete guide to DNS record types, see our DNS record types reference. To check how records are propagating globally, see our DNS propagation guide.