When a DNSSEC-validating resolver cannot verify an answer's signatures, what does the client receive, and why does it look like an outage?
answer
- fail closed, not fail open
- RCODE 2 and no records
- the same code as an unreachable server
- extended errors may say why
basics
~20 sThe client gets SERVFAIL (RCODE 2) and no records: the resolver withholds bogus data rather than pass on a possible forgery. SERVFAIL also reports unreachable or broken servers, so to users the domain simply seems down.
solid answer
~50 sRFC 4035 §5.5 says that when none of the `RRSIG`s can be validated, the response is bad, and a resolver answering a recursive query **must** return `RCODE 2` (SERVFAIL); it returns the full response only if the query set `CD`. That is a deliberate fail-closed choice: most clients never look at the `AD` bit, so handing the records over with a warning would let a forgery through. The cost is ambiguity. SERVFAIL is the same code a resolver gives when it cannot reach a zone's servers, so a user sees "the site is down", not "the signature is bad". RFC 8914's Extended DNS Errors can attach a reason, such as 6 (DNSSEC Bogus) or 7 (Signature Expired), but they are unauthenticated hints that must not change how the client handles the rcode. A client that retries a non-validating resolver gets exactly the data the first one refused.
go deeper
Recall that a validation failure reaches the user as SERVFAIL with no records, the same code as a broken or unreachable server, so it looks like an outage.
Explain why the resolver fails closed: AD clear already marks unsigned data, and most clients never check AD. Name the CD exception and the four validation states.
Show what you would read and avoid in production: Extended DNS Errors such as DNSSEC Bogus or Signature Expired as hints, cached failures, and fallback resolvers that silently bypass validation.
Frame the availability cost of failing closed: a zone operator's signing mistake becomes an outage for every validating resolver, and a resolver operator must decide how to absorb that without abandoning validation.
## What the resolver decides A **validating resolver** is a recursive resolver that checks DNSSEC signatures before it answers. RFC 4035 §4.3 says it must be able to sort every RRset into one of four states: - **Secure**: a chain of signed keys runs from a configured trust anchor down to the RRset, and the signature verifies. - **Insecure**: the resolver knows no such chain exists, for example because the zone is not signed. The data are returned, unprotected. - **Bogus**: the resolver expected a valid chain but could not build one, because a signature failed or required DNSSEC records are missing. RFC 4035 notes this may be an attack, but also a configuration error or data corruption. - **Indeterminate**: the resolver cannot even tell whether the RRset should be signed, because it cannot obtain the DNSSEC records it needs. This question is about the bogus case: the zone is supposed to be signed, and the signatures do not check out. ## What the client receives | Resolver's verdict | Query had `CD` clear | Query had `CD` set | |---|---|---| | Secure | `NOERROR` with the records; `AD` set if the client asked for it with `DO` or `AD` | the records | | Insecure | `NOERROR` with the records, `AD` clear | the records | | Bogus | **`SERVFAIL` (`RCODE 2`), no records** | the full response, unfiltered | The rule comes from RFC 4035 §5.5: if none of the `RRSIG`s validates, the response should be considered bad, a resolver serving a recursive query **must return `RCODE 2`**, and it returns the full response **if and only if** the query set `CD` (Checking Disabled). A client sets `CD` only when it intends to validate the data itself. ## Why it fails closed The alternative would be to return the records with the `AD` bit clear and let the client decide. That fails for two reasons: 1. **`AD` clear already means something else.** Insecure data, from an unsigned zone, are returned with `AD` clear. A client could not tell "legitimately unsigned" from "signed, but the signature is forged". 2. **Most clients never check.** An application asking for an address takes whatever address comes back. If bogus data reached it, a forger would succeed against almost everyone. Withholding the data is how a resolver protects clients that do no checking of their own. The price is paid in availability: a broken signature makes a name unresolvable. ## Why it looks like an outage `RCODE 2` is defined in RFC 1035 as **server failure**, and resolvers use it for many unrelated problems: - every authoritative server for the zone is unreachable or not answering; - a network error while talking to another server; - the zone's servers reply with server failures of their own; - a DNSSEC validation failure. To a browser, a mail server or a user, all of these mean the same thing: the name does not resolve. Nothing in the rcode says "this was refused because the signatures failed", which is why a validation failure is so often reported as "their site is down" and treated as a network outage. Two extra effects make it look stranger still. A resolver may cache the failure: RFC 2308 allows caching a server failure for up to five minutes, and RFC 6840 §3.1 recommends a **BAD cache** of answers that failed validation, so a failure can outlast its cause by a few minutes. And a domain that fails on one resolver may resolve fine through another, because the other one does not validate. ## What Extended DNS Errors add RFC 8914 defines an **Extended DNS Error (EDE)** option, carried in the EDNS0 `OPT` record, with a numeric `INFO-CODE` and optional text. Several codes speak to validation: | `INFO-CODE` | Name | |---|---| | 5 | DNSSEC Indeterminate | | 6 | DNSSEC Bogus | | 7 | Signature Expired | | 8 | Signature Not Yet Valid | | 9 | DNSKEY Missing | | 10 | RRSIGs Missing | These let a human, or a log, see why a SERVFAIL happened. They do not change the protocol: RFC 8914 says EDE content is **unauthenticated**, should be treated only as diagnostic information, and **must not alter DNS protocol processing**. A client still treats the SERVFAIL as a failure. ## The retry trap RFC 8914's own motivation names the risk. A stub resolver that receives SERVFAIL usually just asks the **next configured resolver**. If that one also validates, it fails too. If it does not validate, the client receives the very records the first resolver refused, which may be forged. So listing a validating and a non-validating resolver together on one client quietly turns DNSSEC protection off whenever it matters most.
- Why doesn't a validating resolver return the bogus records with the AD bit clear and let the client decide?Because `AD` clear already describes insecure data from unsigned zones, which are returned normally. A client could not tell a legitimately unsigned answer from a forged signed one, and most applications never examine `AD` at all. Withholding the records with SERVFAIL, as RFC 4035 §5.5 requires for `CD`-clear queries, is what protects clients that do no validation of their own.
- Why is it risky to configure a client with one validating and one non-validating resolver?On SERVFAIL a stub usually retries the next resolver in its list. RFC 8914 points out that if the next one does not validate, the client gets back the very records the validator refused as bogus. The pairing therefore removes DNSSEC protection exactly when an answer has failed validation, which is when it matters.
A pharmacist who finds a broken tamper seal on a bottle does not hand it over with a warning; the shelf just reads "unavailable". That protects every customer, but to the customer it looks like a stock-out, and the shop next door may sell the same bottle without checking the seal.
saying these in an interview costs you the question
- A failed DNSSEC check comes back to the client as NXDOMAIN.
- The resolver returns the bogus records with AD clear as a warning.
- An Extended DNS Error tells the client to ignore the SERVFAIL.
- A SERVFAIL on one domain means its authoritative servers are down.
- Adding a non-validating fallback resolver keeps DNSSEC protection intact.