What DNSSEC protects, and what it leaves open
DNSSEC (DNS Security Extensions) adds digital signatures to DNS records. A validating resolver checks those signatures, so it can tell whether an answer was signed with the zone's keys and arrived unaltered. That stops forged answers, such as those used in cache poisoning, from being accepted.
DNSSEC protects the authenticity and integrity of answers. Several things stay outside its reach:
- Queries and answers still travel unencrypted, so anyone on the path can see which names you look up. DNS over HTTPS and DNS over TLS address that.
- Validation usually happens at the recursive resolver. The hop from the resolver to your device is unprotected unless your device validates too or uses encrypted DNS.
- If an attacker takes over your DNS host or registrar account, their changes are signed like yours.
- A valid signature says nothing about the website or mail server at the address returned.
The records that make DNSSEC work
A signed zone publishes extra record types alongside its ordinary records.
- DNSKEY holds the zone's public keys at its apex. Many zones use two: a key-signing key (KSK) that signs the DNSKEY set, and a zone-signing key (ZSK) that signs everything else.
- RRSIG is a signature over one record set, such as all A records for www. Each signature has an inception and an expiration time, so signatures must be renewed regularly.
- DS (delegation signer) is a hash of the child zone's key-signing key, published in the parent zone. You submit it through your registrar, or your DNS host does it for you.
- NSEC and NSEC3 prove that a name or record type does not exist, so a forged NXDOMAIN can be detected too.
How the DNSSEC chain of trust works
A validating resolver starts with one key it already trusts: the root zone's key-signing key, configured as a trust anchor. From there, each zone vouches for the next one down through a DS record.
For www.example.com, the resolver checks the root's DNSKEY against its trust anchor, then uses it to verify the root's signed DS record for .com. That DS must match the .com DNSKEY, which in turn verifies the signed DS for example.com. Finally, the DNSKEY of example.com must match that DS and verify the RRSIG on the www record.
When every link checks out, the answer is secure, and the resolver can set the AD (authenticated data) flag. A zone whose parent publishes no DS record is treated as unsigned, and its answers are accepted without validation. If any link fails, the answer is bogus and the resolver discards it.
What a DNSSEC validation failure looks like
A validating resolver that receives a bogus answer returns SERVFAIL instead of the data. Browsers then show the same "can't be reached" error as for an outage, so DNSSEC failures are easy to mistake for a server problem.
The usual clue is that the site works on some networks and fails on others. Resolvers that validate, including Cloudflare, Google and Quad9, return SERVFAIL, while a resolver that does not validate still returns the record.
To confirm, repeat the query with checking disabled using dig +cd. Recent versions of dig also print an EDE line (Extended DNS Errors, RFC 8914) when the resolver gives a reason, such as DNSSEC Bogus or Signature Expired.
# Normal query to a validating resolver
dig @1.1.1.1 example.com A
# "status: SERVFAIL" means no valid answer could be returned
# Same query with DNSSEC checking disabled
dig @1.1.1.1 example.com A +cd
# An answer here, but not above, points to a DNSSEC problem
# Show the DS record the parent zone publishes
dig example.com DS +shortCommon ways DNSSEC breaks a working domain
The chain breaks when one side of it changes and the other does not.
- The domain moves to a new DNS host while the registrar still publishes the old DS record. The new host signs with different keys, or does not sign at all, so validating resolvers see a broken chain.
- A DS record is added at the registrar before the zone is signed, or copied with the wrong key tag, algorithm or digest.
- Signatures expire because automated re-signing stopped, for example after a signing server or script failed.
- A key rollover replaces the key-signing key without updating the DS record, or removes the old DS before cached copies have expired.
How to move a signed domain without an outage
Remove the DS record at the registrar first, then wait at least the DS record's TTL so cached copies expire. The domain is now unsigned, so changing DNS hosts no longer risks a validation failure.
Next, move the zone and enable signing at the new host. Wait until the new nameservers serve signed answers and the old NS records have expired from caches, then add the new DS record at the registrar. Check that validating resolvers return the records again.