DNSSEC for Site Owners: What It Protects, and When It Isn't Worth Turning On

Most DNS mistakes degrade something. A wrong A record reaches the wrong server; a stale MX record delays mail; a missing TXT record breaks DKIM for one sender.

DNSSEC is different. Get it wrong and the domain stops resolving — everywhere, for everyone, all at once. That asymmetry is the entire decision, and it is why “should I turn this on?” is a more interesting question than the feature list suggests.

What it actually does

DNSSEC adds cryptographic signatures to DNS records, so a resolver can verify that the answer it received came from the zone owner and was not modified in transit.

Three things it is not, since these get conflated: it is not encryption (queries and answers are still readable), it does not make your website secure, and it does not protect against a compromised registrar account. It protects the integrity of DNS answers between the zone and the resolver. That is a real and narrow guarantee.

The chain: one record at the registrar, keys in the zone

DNSSEC works by building a chain of trust from the root down. The link that concerns you sits at your registrar, and it is called a DS record.

The sequence Cloudflare documents is:

1. Enable DNSSEC in the dashboard (DNS Settings → Enable DNSSEC).
2. Cloudflare signs the zone and shows you the DS values to publish.
3. You add those DS records at your registrar.
4. Resolvers can now validate the chain.

The key algorithm Cloudflare uses is Algorithm 13, which the documentation names as “ECDSA Curve P-256 with SHA-256.”

Two shortcuts exist. If your domain is registered with Cloudflare Registrar, DS publication is handled for you. The .ch and .cz registries also add DS records automatically.

The failure mode is total, not partial

This is the part worth reading twice, in Cloudflare’s own words:

“If you change nameservers before the old DS TTL has fully expired, validating resolvers will return SERVFAIL because the cached DS records will not match Cloudflare’s DNSSEC keys.”

SERVFAIL is not “no answer available.” It is “the answer failed validation.” Resolvers treat it as a hard failure, and Google’s public DNS documentation confirms the behaviour: when it cannot validate, it returns SERVFAIL rather than falling back to an unsigned answer.

There is no graceful degradation, and the reason is that accepting an unvalidated answer is precisely the attack DNSSEC exists to prevent. The system is behaving correctly. That is cold comfort when your domain is down.

One more detail with real operational weight: Google documents that for very heavily trafficked zones it “may temporarily disable validation for the zone until the issue is corrected.” That is a safety valve for Google’s own availability, not a service you should plan around, and it is not available to a small site.

The order that matters

DNSSEC is order-sensitive in both directions, and Cloudflare documents both. Most guides cover the inbound direction and skip the other.

Moving on: you must disable DNSSEC at the registrar before changing nameservers. The documentation explains why, and the reason is more interesting than “otherwise it breaks”: a signed zone has “a single set of signed records,” which “prevents Cloudflare from issuing new DNS records on your behalf.” DNSSEC constrains the provider’s own operational freedom.

Moving back: remove the DS record at the registrar first, then keep the zone signed until the parent’s DS TTL has fully expired. The window depends on the TLD.

The reason this ordering exists is that the DS record lives at the parent and is cached there. You cannot flush somebody else’s cache. You can only wait.

The pending state, and why it stays there

Cloudflare’s API exposes DNSSEC status as active, pending, disabled, pending-disabled, or error, and the documentation defines it as the status “based on user-desired state and the presence of necessary records.”

That definition explains the most common confusion: pending does not mean “still processing.” It means the zone is signed and the DS record has not arrived at the registrar yet. Nothing is happening on Cloudflare’s side. Something is not yet true on the registrar’s side, and no amount of waiting will fix it.

The modern shortcut is CDS/CDNSKEY — RFC 8078 — where the zone publishes a signal and the registry picks the DS record up automatically. For Cloudflare Registrar, the docs state that DS records are submitted automatically via CDS/CDNSKEY scanning that “can take one to two days,” with “no way to manually control the exact timing.” The same RFC also defines the deletion signal, CDS 0 0 0 0, for tearing a chain down cleanly.

The SEO question, answered honestly

Does DNSSEC help rankings?

I went looking for an official statement and found none. Google’s ranking systems guide enumerates the systems it uses and does not list DNSSEC. Its page experience documentation discusses HTTPS, not DNSSEC.

So the accurate answer is: no documented ranking benefit. If you read otherwise, check whether the source cites Google or cites another blog. This is a topic where fabricated authority travels well.

Multi-signer, and when the complexity is justified

There is a zero-downtime migration path, and Cloudflare documents it: multi-signer DNSSEC under RFC 8901. Both providers sign the zone simultaneously during the transition — the old provider must allow a DNSKEY at the apex, the ZSK is cross-imported, and after removing the old DS record you wait at least 1.5 times the DS TTL before removing the old DNSKEY.

It works. It also requires the outgoing provider to cooperate, which is the part that often makes it theoretical rather than practical.

When not to turn it on

• You change providers often. Every move becomes a scheduled, TTL-aware operation with a downtime risk if the timings are wrong.
• Your registrar and DNS provider are different companies, and neither automates DS. You now own a manual step that must happen in the right order.
• The domain is low-value. DNSSEC protects against DNS spoofing on the path to the resolver. Ask what an attacker gains from spoofing your particular domain before deciding it is worth an outage mode.
• You would not notice for a day. The failure is loud to users and quiet to you unless something is monitoring DNS specifically. Combined with the previous article’s point about self-hosted monitoring losing its vantage point during a network incident, this is a genuine risk.

CAA: the record that solves a different problem with less risk

If your motivation is “I want to restrict who can do things with my domain,” CAA may be what you actually want, and it carries no outage mode.

A CAA record names which certificate authorities are allowed to issue certificates for your domain. There is no chain to break, no DS record to synchronise, and no cross-provider ordering. If you get it wrong, certificate issuance fails — a visible, recoverable problem rather than a resolution blackout.

Three documented behaviours worth knowing: CAA applies to subdomains through inheritance; Cloudflare will automatically append its own CAA entries if you have Universal SSL and have added any CAA records yourself; and CAA on the target of a CNAME also applies, with the target’s policy taking precedence.

For a small site, CAA gives you the control benefit at a fraction of the operational cost. DNSSEC gives you cryptographic assurance with a failure mode that requires a calendar and a stopwatch to manage safely.