Now that we understand the chain of trust, we look at how a recursive resolver actually performs validation. The resolver doesn't just fetch the A record; it performs a cryptographic audit of every step from the Root down to the leaf record. Based on this, it marks the response with specific flags.
When a resolver successfully verifies a record using the full DNSSEC chain, it sets the **AD bit** in the DNS header. This tells the client (the stub resolver on the laptop) that the data is 'Authenticated' and the chain of trust is intact. If the AD bit is 0, the data is either not signed or the validation failed.
💡 Note: The AD bit is only trustworthy if the connection between the client and the resolver is secure (e.g., via DNS-over-TLS). Otherwise, an attacker can just flip the AD bit to 1 in a spoofed packet.
In the output above, the `ad` flag confirms that Google's public DNS resolver has validated the DNSSEC chain for this request. If you see `ad` missing from a signed domain, something is wrong with the chain.
The **CD bit** is used by administrators for debugging. When a client sets the CD bit to 1, it tells the recursive resolver: 'Do not perform validation. Just give me the records, even if they are Bogus'. This allows a security engineer to see the actual incorrect RRSIG or DNSKEY that is causing a failure.
⚠️ Never enable the CD bit in a production application. It bypasses the primary security mechanism of DNSSEC and makes the application vulnerable to spoofing.
| Status | Meaning | AD Bit | Resolver Action |
|---|---|---|---|
| Secure | Chain verified to Root | 1 | Return data |
| Insecure | Not signed, but chain is valid | 0 | Return data |
| Bogus | Signed, but chain is broken | 0 | Return SERVFAIL |
| Indeterminate | Validation timed out | 0 | Return SERVFAIL |
The most critical part of validation is the 'Bogus' state. If a resolver finds a signature that is invalid, or a DS record that doesn't match the DNSKEY, it must NOT return the data. Instead, it returns a `SERVFAIL` (Server Failure). This is a 'fail-closed' design: it is better for the website to be offline than for the user to be sent to a malicious IP.
Some 'optimizing' resolvers ignore DNSSEC errors and return the data anyway to avoid breaking the user's experience. This completely defeats the purpose of DNSSEC.
Verify exercises to earn ★ 150 XP and unlock next lab level.