9. DNSSEC

DNS had no authentication. A resolver accepted whatever answer arrived first and matched on 32 bits of luck. DNSSEC fixes that — and the thing it fixes, and the thing it does not, are both worth being precise about.

   DNSSEC PROVIDES
     ORIGIN AUTHENTICITY  this answer came
                          from the zone's
                          owner
     INTEGRITY            it was not
                          modified in
                          transit
     DENIAL OF EXISTENCE  "this name does
                          not exist" is
                          itself provable

   DNSSEC DOES NOT PROVIDE
     CONFIDENTIALITY      queries and
                          answers are still
                          plaintext. that is
                          chapter 10.
     AVAILABILITY         it makes outages
                          MORE likely, not
                          less.

The records

   DNSKEY   a public key, published in the
            zone.
   RRSIG    a signature over one RRset,
            with validity dates.
   DS       Delegation Signer: a HASH of a
            child's DNSKEY, published in
            the PARENT.
   NSEC /
   NSEC3    the proof that a name does not
            exist.
   CDS /
   CDNSKEY  a child's signal to the parent
            about what the DS should be.

dig +dnssec example.com A
dig +short example.com DNSKEY
dig +short example.com DS @a.gtld-servers.net
dig +dnssec example.com | grep RRSIG

   WHAT A SIGNED ANSWER LOOKS LIKE

   ;; flags: qr rd ra ad   ← `ad` =
                             validated

   www.example.com. 300 IN A    203.0.113.42
   www.example.com. 300 IN RRSIG A 13 3 300
       20240701000000 20240617000000 34505
       example.com. Zm9vYmFy…

   SIGNATURES COVER AN RRSET, NOT A MESSAGE.
   so the same signature is reused for every
   query for that name and type, and it is
   computed when the zone is signed, not per
   query.

That last point is the design decision that makes DNSSEC deployable at all: signing is offline. An authoritative server serving a signed zone does no cryptography per query — it looks up a precomputed signature. The cost is that signatures expire on a schedule, which is the source of most DNSSEC outages.

The chain of trust

   ROOT ZONE
     the KSK's hash is the TRUST ANCHOR,
     shipped with every validating resolver
          │ signs
     root ZSK
          │ signs
     com. DS  ──────── hash of com's KSK
          │
   COM ZONE
     com KSK → com ZSK
          │ signs
     example.com. DS ── hash of example's KSK
          │
   EXAMPLE.COM ZONE
     example KSK → example ZSK
          │ signs
     www.example.com. A

   VALIDATION WALKS DOWN

   1. I trust the root KSK (built in).
   2. the root's RRSIG over com's DS
      validates → I trust com's DS.
   3. com's DNSKEY hashes to that DS →
      I trust com's keys.
   4. com's RRSIG over example.com's DS
      validates → I trust that DS.
   5. example.com's DNSKEY hashes to it →
      I trust example.com's keys.
   6. the RRSIG over the A record
      validates → the answer is authentic.

   ONE BROKEN LINK = SERVFAIL. not a
   warning, not a downgrade. the answer is
   WITHHELD.

Danger

“One broken link equals SERVFAIL” is the whole operational story of DNSSEC. A missing DS, an expired signature, a key rolled without updating the parent, or an unsigned child under a signed parent all produce a total outage for every validating resolver — which is roughly 30–40% of global queries, and includes 8.8.8.8 and 1.1.1.1. The domain is not degraded. It does not resolve.

KSK and ZSK

   WHY TWO KEYS

   KSK (Key Signing Key)
     signs only the DNSKEY RRset.
     its hash is in the parent as the DS.
     rolling it requires the PARENT to
     change → slow, coordinated, risky.
     so: large, long-lived.

   ZSK (Zone Signing Key)
     signs everything else.
     rolling it requires nothing outside
     the zone.
     so: smaller, rolled often.

   THE SPLIT EXISTS TO MAKE ROUTINE KEY
   ROLLOVER A LOCAL OPERATION.

   ALGORITHMS, IN PRACTICE

   8   RSA/SHA-256    still common, large
                      keys, large answers
   13  ECDSA P-256    THE RECOMMENDED
                      DEFAULT. small
                      signatures, fast.
   14  ECDSA P-384
   15  Ed25519        excellent, support
                      still not universal
   16  Ed448
   5, 7, 10           deprecated
   1 (RSA/MD5)        forbidden

Algorithm 13 is the answer for a new deployment. The reason is answer size: an RSA-2048 DNSKEY response can exceed 1232 bytes and force TCP, while ECDSA keeps it comfortably inside one packet, which removes a whole class of fragmentation and middlebox failure.

Proving a name does not exist

This is the genuinely clever part, and the source of DNSSEC’s privacy complaint.

   THE PROBLEM
     you cannot sign an answer for a name
     that does not exist, because there is
     nothing to sign — and signing on
     demand would mean an online private
     key.

   NSEC: SIGN THE GAPS.
     sort every name in the zone, and for
     each one publish "the next name is X".

     a.example.com. NSEC m.example.com.
       A RRSIG NSEC

     asked for g.example.com? the signed
     record above PROVES nothing exists
     between a and m. therefore g does not
     exist.

   THE SIDE EFFECT: ZONE WALKING.
     follow the NSEC chain and you enumerate
     the entire zone. every hostname.

   NSEC3: HASH THE NAMES FIRST.
     the chain is over SHA-1 hashes of
     names, with a salt and iteration count.
     enumeration now requires a dictionary
     attack rather than a walk.

   AND NSEC3 WAS LARGELY DEFEATED ANYWAY by
   GPU hashing, which is why RFC 9276 now
   recommends 0 ITERATIONS AND AN EMPTY
   SALT — the extra work was costing
   resolvers more than it cost attackers.

dig +dnssec nonexistent.example.com | grep -E 'NSEC|RRSIG'
ldns-walk example.com                # if NSEC
nsec3walker example.com              # if NSEC3, with effort

   NSEC3 OPT-OUT
     a flag letting a zone skip proving
     non-existence for UNSIGNED delegations.
     essential for TLDs with millions of
     mostly-unsigned children — .com uses
     it — and it weakens the guarantee for
     exactly those names.

White lies and online signing

   MODERN PROVIDERS CHEAT, USEFULLY.

   "NSEC WHITE LIES" / "BLACK LIES"
     generate a minimal NSEC record on the
     fly that covers only the queried name.
     requires an ONLINE key.

   WHAT IT BUYS
     no zone enumeration at all
     no NSEC3 hashing cost
     tiny answers

   WHAT IT COSTS
     the private key is on a live,
     internet-facing server.
     Cloudflare, Route 53 and others accept
     that trade; a bank signing offline on
     an HSM does not.

The root key ceremony

   THE ROOT KSK PRIVATE KEY IS HELD IN TWO
   FACILITIES, IN FIPS 140-2 LEVEL 4 HSMs.

   FOUR TIMES A YEAR, IN PUBLIC, FILMED
     − 7 of 14 Trusted Community
       Representatives, each with a
       physical key to a safe deposit box
     − a scripted ceremony, read aloud
     − the HSM signs the next quarter's
       ZSK keysets
     − tamper-evident bags, logged serial
       numbers, an independent auditor

   THE TRANSCRIPTS AND VIDEOS ARE PUBLISHED.
   it is the most transparent key management
   in production anywhere.

The one root KSK rollover to date — KSK-2010 to KSK-2017, executed in October 2018 — was delayed by a year because measurement showed a meaningful number of resolvers would have broken. That caution is characteristic: the root key is the one thing in the system that genuinely cannot be fixed forward.

What DNSSEC is actually used for

Separating the theory from the deployed reality clarifies the cost-benefit considerably.

   IN PRODUCTION, SIGNED DNS UNDERPINS

   DANE FOR SMTP (TLSA)
     the only widely deployed mechanism
     letting a sending server know a
     receiving server's certificate is
     correct. mail has no browser trust
     store.
     required by the German and Dutch
     governments; used by large hosts.

   SSHFP
     host keys in DNS, so first-connection
     fingerprint prompts become
     verifiable.

   OPENPGPKEY / SMIMEA
     key discovery. niche.

   RFC 8198 AGGRESSIVE NSEC
     the performance win: resolvers answer
     NXDOMAIN locally for a whole range.

   AND, INDIRECTLY, EVERY REGISTRY THAT
   REQUIRES IT FOR A TLD TO EXIST.

dig +short _25._tcp.mail.example.com TLSA
dig +short example.com SSHFP

The threat it closes, precisely

   AN ON-PATH OR OFF-PATH ATTACKER WHO CAN
   INJECT A DNS RESPONSE CAN, WITHOUT
   DNSSEC:

   − point a name at their own server
   − obtain a VALID CERTIFICATE for it,
     because ACME's HTTP-01 and DNS-01
     challenges both trust DNS
   − therefore defeat TLS entirely

   THAT LAST STEP IS THE ONE PEOPLE MISS.
   "TLS already protects us" is true only
   if certificate ISSUANCE is not itself
   DNS-dependent — and it is.

Let’s Encrypt’s multi-perspective validation, which performs challenge checks from several network locations, is the mitigation deployed in practice, and it narrows the attack rather than closing it. That is the strongest available argument for signing a zone whose content is otherwise protected by HTTPS.

Why adoption stalled

   SIGNED ZONES, ROUGHLY
     .se, .nl, .cz, .br        50–90%
     .com, .net                ~5%
     global second-level       ~10%

   VALIDATING RESOLVERS
     ~30–40% of queries worldwide
     (8.8.8.8 and 1.1.1.1 both validate)

   WHY THE GAP

   1. THE RISK IS ASYMMETRIC. an unsigned
      zone works. a mis-signed zone is
      gone. the downside dominates.
   2. KEY ROLLOVER AND DS UPDATES NEED
      REGISTRAR SUPPORT, which is often
      bad or absent.
   3. SERVFAIL hides the cause (chapter 7).
   4. IT PROTECTS AGAINST AN ATTACK MOST
      OPERATORS HAVE NEVER SUFFERED, while
      TLS already protects the content.
   5. MULTI-PROVIDER DNS AND DNSSEC FIGHT
      EACH OTHER.

Note

The honest position: DNSSEC is correct, and the cost-benefit is genuinely debatable for a site that is HTTPS-only with HSTS, because TLS already prevents an attacker from impersonating the server. Where DNSSEC earns its keep unambiguously is DANE for SMTP — mail has no equivalent of a browser’s certificate store — and any case where the DNS answer itself is the security decision.

Operating it without an outage

   THE RULES THAT MATTER

   1. AUTOMATE SIGNING AND RESIGNING.
      never sign by hand. BIND's
      `inline-signing` + `auto-dnssec
      maintain`, Knot's automatic signing,
      OpenDNSSEC, or your provider's
      one-click.

   2. MONITOR SIGNATURE EXPIRY AS A
      DEADLINE, not a metric. alert at 50%
      of the validity window.

   3. USE CDS/CDNSKEY and a registrar that
      honours RFC 7344/8078, so key
      rollover does not need a human at the
      registrar.

   4. ROLL KEYS WITH PRE-PUBLICATION
      (ZSK) OR DOUBLE-DS (KSK). never
      remove the old key before the new one
      is everywhere.

   5. TEST WITH A VALIDATING RESOLVER
      BEFORE AND AFTER EVERY CHANGE.

   6. TO TURN DNSSEC OFF, REMOVE THE DS AT
      THE PARENT FIRST AND WAIT OUT ITS
      TTL. removing the signatures first is
      an immediate outage.

dig +dnssec +cd example.com        # bypass validation: does it work then?
delv example.com                   # BIND's validating lookup tool
delv +rtrace example.com
dnsviz probe example.com | dnsviz print
dig +short example.com CDS
rndc dnssec -status example.com

Rule 6 is worth repeating because it is counter-intuitive and the order is the whole thing: DS at the parent out first, signatures second. Doing it the other way leaves validating resolvers with a parent that says “this zone is signed” and a zone that has no signatures, which is the definition of bogus.

What to take from this chapter

• DNSSEC provides origin authenticity, integrity and provable non-existence. It provides no confidentiality and it makes availability worse, not better.
• Signatures cover an RRset and are computed offline, which is what makes serving a signed zone cheap — and why expiry is the main operational hazard.
• The chain runs root KSK → root ZSK → child DS → child KSK → child ZSK → the record, and one broken link is SERVFAIL: a total outage for every validating resolver, around 30–40% of global queries including 8.8.8.8 and 1.1.1.1.
• KSK and ZSK are split so routine rollover is a local operation — only a KSK change requires the parent to act.
• Use algorithm 13 (ECDSA P-256). RSA keys push DNSKEY answers past 1232 bytes and into TCP and fragmentation problems.
• NSEC proves non-existence by signing the gaps, which allows zone walking. NSEC3 hashes the names, was largely defeated by GPUs, and RFC 9276 now recommends 0 iterations and no salt.
• White lies / black lies synthesise minimal NSEC records on demand, eliminating enumeration — at the cost of an online private key.
• The root key ceremony is quarterly, public, filmed and audited, with 7-of-14 physical keyholders; the one rollover so far was delayed a year because measurement said resolvers would break.
• Adoption stalled because the risk is asymmetric (unsigned works, mis-signed is gone), registrars handle DS updates poorly, SERVFAIL hides the cause, TLS already covers most of the threat, and DNSSEC fights multi-provider DNS.
• Operate it by automating signing, alerting on signature expiry as a deadline, using CDS/CDNSKEY, rolling keys with pre-publication or double-DS, and — to disable it — removing the parent’s DS first and waiting out its TTL.

Next: encrypted DNS — DoT, DoH and DoQ, what they do and do not hide, and the centralisation argument they started.