$ dig example.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4211
When a DNSSEC-signed zone breaks, this is what the world sees: no answer at all. A validating resolver that cannot verify a signature refuses to hand back the record, because the entire point of DNSSEC is that an answer it cannot prove is an answer it will not trust. That makes DNSSEC a double-edged tool. It closes off a real class of attack, and it converts certain configuration mistakes into total, instant outages for your domain.
The Problem DNSSEC Solves
Plain DNS has no authentication. When your resolver asks for example.com and gets back an IP, it has no way to know whether that answer came from the real authoritative server or from an attacker who injected a forged reply, the classic cache-poisoning attack. DNSSEC fixes this by having each zone cryptographically sign its records. The resolver checks the signature and knows the answer is authentic and unmodified. It does not encrypt anything; DNS stays public. It only proves integrity and origin.
The Records Involved
DNSSEC adds a handful of record types, and understanding what each does makes the chain make sense.
| Record | Holds | Role |
|---|---|---|
DNSKEY |
The zone's public keys | Used to verify signatures in this zone |
RRSIG |
A signature over a record set | The actual cryptographic signature |
DS |
A hash of a child zone's key | Lives in the parent, links the chain down |
NSEC/NSEC3 |
Proof of non-existence | Proves a name genuinely does not exist |
# see the signature attached to an A record
dig +dnssec example.com a
# see the DS record the parent (.com) publishes for you
dig ds example.com
# see the zone's public keys
dig dnskey example.com
The Chain of Trust
The word "chain" is literal. Trust flows from the root zone down to your records, and each link vouches for the one below it.
. (root) publishes DS for → com.
com. publishes DS for → example.com.
example.com. DNSKEY signs → www.example.com. A record
The resolver starts from the root, whose key it already trusts (the "trust anchor"), and walks down. At each level, the parent's DS record is a hash of the child's DNSKEY. The resolver checks that the child's published key matches the parent's hash, then uses that key to verify the child's signatures, then repeats one level down. If any link fails, verification stops and you get SERVFAIL.
Where the Chain Breaks
Nearly every DNSSEC outage is a break in that chain, and the two most common causes are avoidable.
The first is the DS record. When you enable DNSSEC, you have to publish a DS record at your registrar, so the parent zone (.com) points at your key. If your DS record references a key you no longer use, or you rotate your signing key without updating the DS, the parent is now vouching for a key that no longer signs your zone. The chain snaps.
# the DS at the parent must hash a DNSKEY you still publish
registrar DS: example.com DS 12345 13 2 A1B2C3...
your zone: example.com DNSKEY ... (key tag must be 12345)
The second is signature expiration. Unlike a TLS certificate, RRSIG records expire on the order of days to weeks, and they have to be re-signed continuously. If your signing automation stops, whether the box died or a cron job silently failed, the signatures go stale and every validating resolver on the internet starts returning SERVFAIL for your domain the moment they lapse. There is no grace period.
RRSIG a 13 2 3600 20261115000000 20261101000000 ...
│ │
│ └─ inception
└─ expiration: after this instant, SERVFAIL
Verify From the Outside
Because a break is invisible from inside a non-validating network, check the chain the way a validating resolver would. A DNSSEC checker walks the chain from the root down and shows you exactly which link fails, which turns a bare SERVFAIL into a specific fix. Run it after every key rollover and after any registrar change, the two moments the DS record is most likely to fall out of sync.
DNSSEC Underpins Other Controls
DNSSEC is the foundation that makes DANE and TLSA records trustworthy, and it hardens the CAA and MX lookups that certificate issuance and mail routing depend on. A poisoned CAA record answer could let an attacker get a certificate issued for your domain; DNSSEC closes that door. That interconnection is also the risk: because so much hangs off DNS, a DNSSEC break takes all of it down at once. Monitoring the endpoints that depend on those records is the backstop. Generator Labs certificate monitoring checks the CAA records and TLS endpoints across your infrastructure, so a DNS-layer problem that starts affecting issuance or reachability surfaces as an alert before a user reports it. Start monitoring.