DNSSEC explained: what it signs, what it does not, and how to enable it

DNS answers arrive with no proof of origin. A resolver asks where example.com lives and accepts whatever comes back, which is why cache poisoning and on path spoofing have been viable attacks for as long as DNS has existed. DNSSEC adds cryptographic signatures to DNS records so a validating resolver can verify that an answer came from the zone's real operator and was not modified in transit. It does not encrypt anything, and that distinction is the source of most misunderstandings about it.

You can check whether a domain is signed, and see its DNSSEC records, with the DNS Lookup tool.

What DNSSEC proves

Three properties, and only these three:

• Authenticity. The answer came from the zone's keyholder.
• Integrity. Nothing changed it on the way.
• Authenticated denial. "This name does not exist" is itself signed, so an attacker cannot suppress a record by pretending it is absent.

What it explicitly does not provide is confidentiality. DNSSEC queries and answers travel in plaintext exactly as before, and anyone on the path still sees every domain you look up. That problem is solved by DNS over HTTPS or DNS over TLS, which encrypt the transport but say nothing about whether the answer is genuine. The two are complementary: encryption hides the lookup, DNSSEC proves the answer.

The record types

DNSSEC introduces four record types, each with a specific job.

Every record set in a signed zone gets an RRSIG alongside it. A resolver fetching the A record for example.com also fetches the RRSIG covering it, then verifies that signature against the zone's DNSKEY.

That raises the obvious question: how does the resolver know the DNSKEY is genuine? Because the parent zone publishes a DS record, a hash of the child's key, and that DS record is itself signed by the parent's key. The same argument repeats upward: .com is signed and its DS sits in the root zone, and the root's key is the one thing shipped with the resolver software itself, the trust anchor. That unbroken sequence from root to your zone is the chain of trust, and if any link is missing the domain is simply unsigned rather than invalid.

In practice zones use two keys: a key signing key that signs only the DNSKEY set and is referenced by the parent DS, and a zone signing key that signs everything else. The split lets you rotate the working key frequently without touching the parent, which is the slow and fragile part.

What a validating resolver does

When a resolver with validation enabled looks up a signed name, it walks the chain from the root down, verifying each signature. Three outcomes:

• Secure. The chain validates. The answer is returned with the AD (authenticated data) flag set.
• Insecure. No DS exists at some point, so the zone is not signed. The answer is returned normally. This is the majority of the internet.
• Bogus. A DS exists but validation fails: a bad signature, an expired one, a key mismatch. The resolver returns SERVFAIL and no address at all.

That third case is the one to internalise. A DNSSEC failure is not a warning; it is a total outage for every user behind a validating resolver, which now includes Google Public DNS, Cloudflare 1.1.1.1, Quad9, and a growing share of ISPs. Users cannot click through it, and the site appears completely down while working fine for anyone on a non validating resolver, which makes the symptom deeply confusing until you check the flag.

Signatures also expire. RRSIG records carry validity windows, typically days to weeks, and a signing process that stalls takes the domain offline when the last signature lapses, without anybody touching the zone. Managed DNSSEC handles resigning automatically; self managed signing needs monitoring.

Enabling it

At a registrar and DNS host that both support it, this is now a two step operation:

1. Sign the zone at your DNS host. Modern providers do this with one toggle, generating and rotating keys for you.
2. Publish the DS record at your registrar. Some providers do this automatically over the registrar API; otherwise you copy the key tag, algorithm, digest type, and digest from the DNS host into the registrar's DNSSEC form.

Step two is the whole point. Signing a zone without a DS in the parent achieves nothing, because no resolver has any reason to expect signatures. Verify afterwards that the DS is visible in the parent and that lookups return the AD flag:

dig example.com +dnssec +multi
dig DS example.com @a.gtld-servers.net

Prefer algorithm 13 (ECDSA P-256) over algorithm 8 (RSA/SHA-256) for new deployments. The signatures are dramatically smaller, which keeps responses under UDP size limits and reduces truncation and fragmentation problems, and the security level is equivalent or better. The tradeoff between key types is the same one described in symmetric vs asymmetric encryption.

The one mistake that takes you offline

Changing DNS providers while DNSSEC is enabled. The new provider signs with its own keys, the parent DS still points at the old provider's key, the chain breaks, and every validating resolver returns SERVFAIL. The domain goes dark, and because the DS sits in the parent zone with its own TTL, the recovery is slower than the mistake.

The correct sequence is to disable DNSSEC first (remove the DS at the registrar, wait for its TTL to expire), then migrate, then re enable signing at the new provider. Providers that support key import or multi signer setups can do this without a gap, but the safe default is to unsign, move, resign.

Two related pitfalls:

• Rolling keys without overlap. Publish the new key, wait a full TTL so caches hold both, then remove the old one. Swapping in one step strands every cached copy.
• Long TTLs on DNSKEY and DS. They make every recovery slower. Keep them modest, and see DNS propagation explained for how TTLs govern how long a mistake persists.

Is it worth enabling?

For most sites, DNSSEC is a modest security improvement over an attack that is already uncommon on the modern web, where HTTPS plus certificate validation already stops an attacker who spoofs your DNS from presenting a valid certificate. The clearest wins are elsewhere:

• Email, where MTA-STS and DANE depend on DNS being trustworthy, and where SPF, DKIM, and DMARC all rest on DNS answers.
• Certificate issuance, since DNS based domain validation and CAA records are both DNS lookups a CA performs on your behalf.
• Compliance, where it is often simply required.

If your DNS host offers managed DNSSEC with automatic DS publication, enable it: the failure modes above are mostly failures of manual key handling. If you manage signing yourself, add signature expiry to the same monitoring that watches certificate expiry, and confirm records with the DNS Lookup tool after every change.