DNSSEC and defense in depth — What it protects and what remains
Pin down what DNSSEC covers and the limits at the last hop, and assemble defense in depth around it.
Recap of the previous chapter: In Chapter 4 we organized the combination of short-term hardening (patch, entropy, recursion restriction, monitoring) drawn from the lessons of 2008. In this chapter we go further and confirm what DNSSEC protects, what it does not, and what remains at the "last hop."
DNSSEC is a mechanism of "verify with signatures"
DNSSEC signs DNS data so that a resolver can follow those signatures and validate them. At its center are origin authentication and integrity — not confidentiality of the communication itself.
The trust chain follows from the parent's DS to the child's DNSKEY, and then to the RRSIG that covers the RRset.
What it provides / what it does not
Practice 5-1 — What it protects and what it does not
Separate "verification by signature" from "confidentiality."
Q1. Which of the following does DNSSEC not provide?
DNSSEC provides data origin authentication, data integrity, and authenticated denial of existence (signed proof that a name does not exist), but it does not provide confidentiality (keeping the contents of queries and responses secret). Confidentiality is the job of separate mechanisms such as DoT / DoH.
Q2. Which of these does DNSSEC, in principle, not provide?
DNSSEC is centered on signature-based verification and does not provide confidentiality of query or response contents themselves. If confidentiality is needed, you have to consider separate channel protection or design.
Q3. Which option best describes the role of the DS record?
The DS record lives on the parent side and gives the handle used to reference the child zone's DNSKEY. That is what extends the trust chain into the child.
Distinguishing secure / insecure / bogus
If validation succeeds for a signed zone, it is secure. Some zones are unsigned / insecure because the parent has no DS. On the other hand, if the parent has a DS but the child's keys or signatures cannot be followed, you have to treat it as bogus.
| State | Situation of DS / key / signature | Meaning |
|---|---|---|
| secure | DS present, DNSKEY / RRSIG validation also succeeds | Signature verification holds |
| insecure | No DS at the parent (unsigned zone) | No DNSSEC guarantee, but within the expected design |
| bogus | There is a DS, but validation does not succeed | Suspicion of tampering or misconfiguration; must not be used as a response |
Practice 5-2 — Distinguishing secure / insecure / bogus
The state is decided by whether a DS exists and by the outcome of DNSKEY / RRSIG validation.
Q4. The parent has a DS, but validation of the child's DNSKEY / RRSIG fails. Which treatment by a validating resolver is closest?
If the parent has a DS but the child's DNSKEY / RRSIG cannot be validated, treating the zone as bogus is the closest answer. It is neither secure nor insecure.
The last-hop problem
Even if the recursive resolver validates, a stub cannot always trust that resolver or the channel to it sufficiently. RFC 4033 explains that, for a security-aware stub resolver to actually benefit from DNSSEC, it has to trust both the recursive server and the channel.
So the AD bit is a useful hint, but it is not a universal end-to-end proof.
In such environments, you have to combine DNSSEC with separate mechanisms that protect the channel between stub and recursive (DoT / DoH, or pinning a trusted resolver behind IPsec, etc.).
Seeing signature validation in practice — dig +dnssec output
The concept is hard to grasp from words alone, so confirm it with real dig output. When you query a signed zone (e.g. example.) with +dnssec, the flags include ad, and RRSIG records appear in the ANSWER section.
$ dig +dnssec example. SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example. IN SOA
;; ANSWER SECTION:
example. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2024010101 7200 3600 1209600 3600
example. 3600 IN RRSIG SOA 8 1 3600 20260601000000 20260501000000 12345 example. AbCdEf...(signature data)
Two things to notice here:
ad is set in flags
RRSIG appears in ANSWER
Conversely, in a bogus situation (DS exists but validation does not succeed), you will see status: SERVFAIL with an empty ANSWER. That is the implementation embodying "responses that fail validation must not be used."
Assembling it as defense in depth
Neither DNSSEC alone, nor query matching or port entropy alone, is sufficient by itself. It is realistic to stack the entry (patch, recursion restriction), matching conditions (ID / port / question / bailiwick), verification (DNSSEC), and operations (monitoring and logs).
Practice 5-3 — Last hop and defense in depth
Read the AD bit and defense in depth while being mindful of where the trust boundary lies.
Q5. Which statement about the AD bit, seen from a stub resolver, is most appropriate?
The AD bit is a hint to be read on the assumption that you trust a validating recursive resolver and the channel to it. If the stub does not trust that party or channel, AD=1 cannot be taken as a universal end-to-end guarantee.
Q6. Which description of protecting a modern resolver is most balanced?
Defense of a modern resolver is layered. Realistically you stack patching, query matching, ID/port entropy, glue hardening, recursion control, and DNSSEC validation.
Takeaways from this chapter
- DNSSEC provides origin authentication / integrity / authenticated denial of existence.
- Confidentiality is a separate problem and cannot be obtained from DNSSEC alone.
- Read the AD bit and a validating resolver's result together with the last-hop trust problem.
- Do not rely on any single mechanism; stack patch, entropy, bailiwick, DNSSEC, and monitoring.