How DNSSEC breaks in production

DNSSEC fails closed. That is the correct design and it means a signing mistake is an outage rather than a warning — for everyone behind a validating resolver, which is a large and growing share of users. These are the five ways it happens in practice.

1. Expired signatures

The most common by a distance. Signatures have wall-clock expiry dates, so a zone must be re-signed on a schedule. If whatever does the re-signing stops — a failed cron job, an expired credential, a migration that left the signer behind — nothing is wrong until the expiry passes, and then the domain disappears completely and without warning.

RRSIG SOA 13 2 3600 20260924000000 20260903000000 29357 ...
                            ^^^^^^^^^^^^^^
                            after this instant: SERVFAIL, everywhere

Monitor the remaining validity, not merely whether the zone resolves. By the time it stops resolving you have had an outage for however long it took someone to notice.

2. DS not updated at a key rollover

The zone rolls to a new key-signing key and the DS in the parent still refers to the old one. The parent is vouching for a key that no longer exists, so validation fails — and it fails because DNSSEC is working.

This is structurally likely because the two live in different systems. Your DNS provider holds the keys; your registrar holds the DS. Anything that touches one without the other — a provider migration, a registrar transfer, a "regenerate keys" button — can produce it.

3. A record changed without re-signing

Signatures cover RRsets. Add a record to a signed zone without re-signing that set and the signature no longer matches the data.

Automated record changes are the usual trigger

ACME DNS-01 certificate issuance writes a _acme-challenge TXT record, waits for it to be visible, and deletes it. On a signed zone every one of those steps must re-sign the zone and bump the serial so secondaries pick it up. If it does not, the certificate authority either sees an unsigned record and fails validation, or sees nothing because the change never reached the servers it queried. The symptom is an intermittent renewal failure with a healthy-looking zone, which is a genuinely unpleasant thing to diagnose.

4. The child is signed and the parent was never told

Keys generated, zone signed, DS never submitted. Everything looks configured and no validator is doing anything, because without a DS there is no chain. The zone is unsigned as far as the internet is concerned.

Harmless in the sense that nothing breaks, and it means a control believed to be deployed is not. Registrar transfers cause this too: the DS is often dropped and has to be re-submitted afterwards.

5. Algorithm mismatch or an unsupported algorithm

The DS names an algorithm and so does the DNSKEY. They must agree. Separately, some algorithms are deprecated and some validators will not accept them.

Algorithm	Number	Status
RSA/SHA-1	5, 7	Deprecated. Do not use.
RSA/SHA-256	8	Widely supported. Fine.
ECDSA P-256/SHA-256	13	Recommended. Smaller signatures, broad support.
Ed25519	15	Good where supported; support is not yet universal.

Per RFC 8624. Algorithm 13 is the sensible default for a new zone today.

Diagnosing quickly

# 1. does a validating resolver accept it?
dig +dnssec example.com @1.1.1.1 | grep -E 'status:|flags:'

# 2. is there a DS at the parent?
dig +short DS example.com @1.1.1.1

# 3. does the zone publish a key with the same tag and algorithm?
dig +short DNSKEY example.com @1.1.1.1

# 4. are the signatures still in date?
dig +noall +answer +dnssec SOA example.com @1.1.1.1

SERVFAIL, DS present, DNSKEY present — check the RRSIG dates, then the key tags.
Resolves fine, no ad flag, no DS — unsigned, or signed-but-unconnected.
Works on one resolver, SERVFAIL on another — one validates and the other does not. The one returning SERVFAIL is right.

Knowledge check

A domain resolved normally yesterday. Today users on some networks cannot reach it, while others are unaffected. dig @1.1.1.1 returns SERVFAIL; dig against the domain's own nameservers returns a normal answer. What is the most likely cause?

The authoritative nameservers are partially unreachable, so some resolvers cannot get an answer.
DNSSEC validation is failing — most likely expired signatures. Validating resolvers return SERVFAIL while non-validating ones serve the answer.
A TTL problem — some resolvers are still serving a cached good answer.
The registrar has suspended the domain.

Not this — The authoritative nameservers are partially unreachable, so some resolvers cannot get an answer. The authoritative servers are answering normally when queried directly, so they are reachable. And a reachability problem would not split cleanly along the line of which resolver a user happens to use.

Correct — DNSSEC validation is failing — most likely expired signatures. Validating resolvers return SERVFAIL while non-validating ones serve the answer. This is the signature pattern of a DNSSEC failure: the data is fine at the source, and only resolvers that check the signatures refuse it. "Yesterday it worked" points at expiry specifically, because nothing has to change for a signature to become invalid — a date passes. Check the RRSIG expiration first.

Not this — A TTL problem — some resolvers are still serving a cached good answer. That would produce the opposite pattern, with cached resolvers working and fresh lookups failing, and it would resolve itself as caches expired rather than persisting.

Not this — The registrar has suspended the domain. A suspension removes the delegation, so every resolver fails and the authoritative servers stop being consulted at all. Here they are answering correctly and only validating resolvers object.