DNSSEC explained, and how to enable it safely

What DNSSEC proves, and what it does not

DNSSEC proves two things about a DNS answer: that it was published by whoever holds the zone's signing key, and that it has not been altered in transit. It also proves the harder negative case, that a name genuinely does not exist, which matters because an attacker who can convince a resolver that a name is absent can do plenty of damage without ever forging a record.

It does not encrypt anything. Every DNS query and answer remains in the clear, visible to anyone on the path, and DNSSEC adds records rather than hiding them. Confidentiality on the wire is the job of DNS over TLS or DNS over HTTPS, which are unrelated mechanisms solving a different problem.

It does not say anything about the content of the records. A signed zone that points at a compromised server publishes a perfectly valid signature over a perfectly wrong address. DNSSEC is an integrity and authenticity mechanism for the publishing step, and nothing more.

It does not protect the last hop on its own. If your laptop asks a resolver that validates, the validation happens at the resolver, and the answer travels the remaining distance to you unsigned. That is the ordinary deployment and it is still worth having, because the cache-poisoning attacks DNSSEC defends against target resolvers rather than end machines.

And it does nothing for a domain nobody attacks this way. The honest case for signing is specific: it closes off cache poisoning and forged answers, it is a prerequisite for DANE and TLSA records, and it removes DNS as a path to fraudulently obtaining a certificate, since domain validation itself runs over DNS. That is a real set of benefits and a real operational commitment, which is why our scan reports an unsigned zone as information rather than as a failure.

The records, and how the chain of trust is built

Four record types do the work, and each answers one question.

• DNSKEY holds the zone's public keys. It lives at the zone apex and is itself signed.

• RRSIG holds a signature over one set of records, along with the key tag that made it and a validity window with an inception and an expiration time. Every authoritative record set in a signed zone carries one.

• DS is a hash of one of your DNSKEY records, published not in your zone but in the parent zone. It is the link in the chain, and it is the reason DNSSEC involves your registrar as well as your DNS host.

• NSEC or NSEC3 proves that a name does not exist, because you cannot sign an answer you are not giving.

The chain runs downward. A validating resolver starts with the root zone's key, which is built into the resolver as its trust anchor and is the only key it trusts a priori. The root zone publishes a DS record for com, signed with the root key. The com zone publishes a DS record for example.com, signed with com's key. Your zone publishes DNSKEY records whose hash matches that DS, and every record set in your zone carries an RRSIG made with one of those keys. Each link is verified against the one above it, and if any link fails the resolver returns SERVFAIL rather than an answer.

Two kinds of key exist because the two jobs have different costs. The key-signing key, or KSK, signs only the DNSKEY record set, and it is the key your DS record is a hash of. The zone-signing key, or ZSK, signs everything else. The split means the ZSK can be rotated as often as you like without touching the parent zone, while the KSK, which requires a registrar interaction to change, can be left alone for much longer. Managed DNS hosts handle both, and the only one you ever see is the KSK, in the DS record you paste into your registrar.

# your zone's public keys
dig +short DNSKEY example.com

# the hash of your key-signing key, published by the parent registry
dig +short DS example.com

# a signature and its validity window
dig +dnssec +noall +answer SOA example.com

NSEC, NSEC3 and zone walking

Proving that something does not exist is the awkward half of DNSSEC. You cannot sign each possible non-answer in advance, so the zone signs statements about the gaps between the names that do exist.

NSEC, defined in RFC 4034 section 4, does this by pointing at the next name in canonical order. A resolver asking for a name that falls between two real names gets back a signed record saying so. The side effect is that following the chain of NSEC records one query at a time lists every name in the zone, which is called zone walking.

NSEC3, defined in RFC 5155, hashes the names before ordering them, so walking the chain yields hashes rather than hostnames. It makes enumeration harder rather than impossible, since those hashes can be attacked offline against a dictionary, and it costs extra work on every negative answer.

Neither is wrong. Our scan reports a zone using NSEC as information, not a fault: it is simpler and cheaper, and enumeration only matters if you have hostnames whose secrecy is doing security work, which is a weak defence you should not be relying on anyway. Choose NSEC3 if the list of names in your zone is genuinely sensitive; choose NSEC otherwise.

If you do use NSEC3, RFC 9276 section 3.1 is unambiguous about the parameters: zero extra iterations and an empty salt. The extra hashing was intended to slow enumeration and analysis has shown it does not meaningfully do so, while the per-query cost to your nameservers and to every validating resolver is real. Some resolvers now cap the iteration count and treat higher values as insecure. We flag a non-zero count for exactly this reason.

Avoid NSEC3 opt-out unless you are a registry. It omits unsigned delegations from the proof, which means the non-existence of a subdomain cannot be proved and a forged delegation cannot be detected. The saving only matters at the scale of millions of delegations.

Choosing an algorithm

Algorithm choice used to be pinned to RFC 8624. That is now out of date in a way worth knowing: RFC 9904, published in November 2025, moves the canonical source of algorithm recommendations out of the RFC series and into the IANA DNS Security Algorithm Numbers registry, so the registry rather than a document is the thing to check. RFC 9904 did not itself change any recommendation.

As the registry stands, algorithm 13, ECDSAP256SHA256, is recommended for signing and for validation, and it is the right default for a new deployment. It is universally supported, and its signatures are far smaller than RSA's, which keeps responses inside sizes that awkward middleboxes will pass. Algorithm 8, RSASHA256, is also recommended for signing and is what a great many older zones use; there is no urgency to move off it.

Algorithm 15, ED25519, is recommended for both as well, and is a reasonable choice where your DNS host and your registry both support it. Algorithms 14 and 16 are marked MAY rather than recommended.

The ones to move off are the SHA-1 based signature algorithms, 5 and 7. They are marked MUST NOT for signing in the registry, and RFC 9905, also from November 2025, deprecates them for creating DNSKEY and RRSIG records. Validators still accept them for now, which means a zone signed with them is not broken today and is running on protection that is being withdrawn.

Key size is judged only for RSA, since each elliptic curve algorithm has exactly one size. If you are rolling an RSA key because it is too short, roll to algorithm 13 instead of to a larger RSA key: equivalent strength, much smaller responses.

Note that an algorithm change is not a settings change. It is a full rollover, with both algorithms published side by side and a new DS at the registrar before the old one is withdrawn, so use your DNS host's managed operation if one exists.

Enabling it, shape one: the one-click case

If your registrar and your DNS host are the same company, or the two support automated DS exchange, enabling DNSSEC is genuinely a single switch and you should take it. The host generates the keys, signs the zone, publishes the DS at the registry on your behalf, and handles rollovers thereafter. The operational risk that makes DNSSEC frightening is almost entirely in the manual DS handling, and this removes it.

Cloudflare's documentation, as of June 2026, describes enabling DNSSEC from the DNS settings page, signing with algorithm 13, and adding the DS record automatically for domains registered through Cloudflare Registrar and for two country-code top-level domains. For every other registrar it gives you the DS values to enter yourself, which is shape two.

Before you flip the switch, check one thing: that the parent zone actually supports DS records. AWS documents the failure directly, and it applies everywhere. If your parent zone is served by a provider that does not answer DS queries authoritatively, enabling DNSSEC in the child zone makes the child unresolvable. This bites on delegated subdomains far more often than on registered domains.

Then check that your DNS host handles key rollover automatically, and confirm what happens if you later move DNS providers. Moving a signed zone between providers while the DS stays published is one of the standard ways domains go dark, and the safe procedure is always to unsign first, move, then re-sign.

Enabling it, shape two: submitting the DS yourself

When the DNS host signs and the registrar is somewhere else, the two halves have to be sequenced. AWS publishes the most detailed public procedure for this and the order it gives generalises well, whoever your provider is.

• Lower the zone's maximum TTL first, and lower the SOA TTL and SOA minimum field. AWS recommends one hour for the zone maximum. This is the step people skip, and it is the one that decides how long a rollback takes: if your longest TTL is a day, a problem after signing takes a day to undo.

• Enable signing at the DNS host and confirm it has taken effect on every one of its nameservers. At this point the zone is signed but nothing validates it, because there is no DS at the registry yet, so nothing can break.

• Wait at least the previous zone maximum TTL, so resolvers flush the unsigned copies they hold.

• Now publish the DS at your registrar, from the values the DNS host gives you. Some registrars want the DS fields, which are key tag, algorithm, digest type and digest; others want the DNSKEY and compute the DS themselves. SHA-256, digest type 2, is the digest every registry accepts.

• Wait for the registry to publish it, and then for resolvers to pick it up. AWS makes a point that is easy to miss: resolvers do not see the new DS until the delegation NS records expire from their caches, so the relevant wait is the maximum NS TTL, not the DS TTL. NS TTLs at a generic top-level domain registry are commonly one or two days and you cannot lower them.

• Confirm with a validating resolver before you walk away, and keep watching. AWS recommends monitoring for two weeks, because some of the problems DNSSEC surfaces are other people's middleboxes truncating larger responses rather than anything in your zone.

Ask your registrar for a low DS TTL if it offers the choice; AWS suggests 300 seconds during the change for faster recovery, raised to an hour once you are satisfied. Most registrars do not let you set it at all.

The failure mode that takes the whole domain offline

A DS record at the registry that does not match any key your zone currently publishes is the worst DNS failure there is, and it deserves to be described exactly.

A validating resolver that holds your DS and cannot verify your zone against it does not fall back to treating the domain as unsigned. RFC 4035 section 5.5 requires it to return SERVFAIL. Your website, your email, your API and anything else under the name simply stop existing for every user of that resolver. Non-validating resolvers keep working perfectly, which is why the outage so often looks intermittent or regional at first, and why it can look fine from your own desk for hours.

Two causes account for most cases: a key-signing key rolled at the DNS host without the new DS being submitted to the registrar, and a zone that stopped being signed, usually during a provider move, while its DS stayed published. A third is a signature that expired because the automation that re-signs the zone stopped running. An expired signature is a scheduled outage nobody scheduled, with no warning and no grace period, which is why we warn a week ahead rather than waiting for the date.

Recovery time is set by TTLs and not by how fast you work. Deleting every DS record at the registrar takes the domain out of the chain of trust and restores resolution for everyone, but only once the registry publishes the change and the old DS falls out of resolver caches. The registry step is usually minutes and is occasionally scheduled once a day; the cache step is bounded by the parent's DS TTL, which for a generic top-level domain is commonly a day and is not yours to shorten. Plan on hours, and know that this is the fast path.

So the emergency procedure is: delete the DS, accept that the domain is unsigned for now, get service back, and fix the mismatch properly afterwards. A domain that resolves unsigned is a downgrade. A domain that does not resolve is an outage.

If you would rather repair than retreat, the alternative is to publish a DS computed from a key the zone actually holds, alongside the broken one rather than instead of it, and remove the stale DS only once the new one is visible at the registry. That avoids any window with no valid DS at all, but it depends on your registrar supporting more than one DS record.

Key rollover, and automating the DS

A zone-signing key rollover is internal: the zone publishes the new key, signs with it, and retires the old one, with no registrar involvement and nothing that can break at the parent. Managed hosts do this on a schedule and you will never notice.

A key-signing key rollover touches the parent and is therefore the risky one. The safe order is always: publish the new key in the zone, submit its DS, wait for the registry to publish it and for the old DS to fall out of caches, and only then withdraw the old key and the old DS. Never remove the old DS first, and never submit a DS for a key the zone has not published yet.

There is a standard way to take the human out of this. RFC 7344 and RFC 8078 define CDS and CDNSKEY records, which a child zone publishes to tell the parent what its DS should be; the registry or registrar polls for them and updates the DS automatically. RFC 9615 adds an authenticated bootstrapping method so the initial DS can be established this way too, rather than requiring an out-of-band step or an accept-after-delay policy. Support varies by registry and registrar, and where it exists it removes the commonest cause of DNSSEC outages entirely. It is worth asking your registrar whether they consume CDS records.

Whatever the mechanism, monitor signature expiry independently of your provider. Our checks warn when any signature is within seven days of expiring, precisely because a signature getting close is itself the evidence that the automation which renews it has stopped.

Turning DNSSEC off safely

Unsigning is a legitimate operation, and it is frequently the right first move before migrating DNS providers. It is safe only in one order, and the order is the reverse of enabling.

• If your zone publishes DS records for signed child zones of its own, remove those first.

• Remove the DS record at the parent. This is the step that takes your zone out of the chain of trust. Contact the registrar, or the parent zone's owner for a delegated subdomain.

• Confirm the removal has actually taken effect at the registry, rather than assuming the request was processed. Some registrars apply DS changes on a schedule.

• Wait out the DS TTL, so that every resolver has forgotten it. Only after this point does no resolver expect your zone to validate.

• Now disable signing at the DNS host and retire the keys.

Doing this in the other order, disabling signing first, produces exactly the outage described two sections above: a DS at the registry with nothing in the zone to match it. If you are moving providers, unsign completely, complete the move, confirm the domain resolves everywhere, and then sign again at the new provider. Do not attempt to carry keys across.

How to verify, and what our check actually checks

There are three levels of verification and they answer different questions. dig tells you what is published. delv does the cryptography. A query against a public validating resolver tells you what the internet experiences, which is the one that matters at two in the morning.

delv is the tool to reach for after any change to keys or DS records: it performs full validation and reports whether the name is fully validated, and delv +vtrace shows each link in the chain so you can see which one failed.

Be explicit about what our own scan does, because a DNSSEC report that says valid without saying what it validated is worth nothing. We recompute the DS digest from your live DNSKEY set and compare it byte for byte with what the registry publishes, we check every RRSIG validity window against the current time, we read algorithms and key sizes, and we ask public validating resolvers whether they can resolve the domain at all. We do not verify the signatures themselves against their keys, we do not walk the chain from the root, and we read denial-of-existence records without validating the proofs. The report says so in as many words rather than implying more. For the cryptography, use delv.

# what is published
dig +dnssec +noall +answer DNSKEY example.com
dig +short DS example.com

# full validation, with the chain shown
delv +vtrace example.com A

# what the internet actually experiences
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
# an answer is good; SERVFAIL from a validating resolver while your own
# nameservers answer normally means the chain of trust is broken

What commonly goes wrong

• Rolling the key-signing key at the DNS host and not updating the DS at the registrar. The commonest cause of DNSSEC outages by a wide margin, and one that surfaces hours later as caches expire rather than immediately.

• Moving DNS providers with the DS still published. The new provider serves an unsigned zone, the registry still says the zone is signed, and the domain goes dark for validating resolvers. Unsign, move, re-sign.

• Disabling signing before removing the DS. The same outage, arrived at from the other direction, and entirely avoidable by following the order.

• Letting signatures expire. Re-signing is normally automatic, so an expiry means the automation stopped. There is no warning at the moment it happens and no grace period: the domain simply stops resolving for a large share of the internet.

• Signing without lowering TTLs first. Everything still works, but every rollback now takes as long as your longest TTL, which is exactly the wrong thing to discover during an outage.

• Enabling DNSSEC on a delegated subdomain whose parent does not answer DS queries authoritatively. The child becomes unresolvable, and nothing about the child's own configuration is wrong.

• Treating the DS TTL as the whole recovery time when publishing a DS. Resolvers only see a new DS once the delegation NS records expire from their caches, and registry NS TTLs of one or two days are normal and not yours to change.

• Assuming a green DNSSEC panel means the signatures were verified. Check what any tool, ours included, actually validated before you rely on it while rolling a key.