What is DNSSEC, and why does the order you enable it in matter?

Every time somebody visits your website or sends you an email, their computer asks the DNS system a question: where does this domain live? The answer that comes back decides where they end up.

Ordinary DNS has no way to prove that answer is genuine. It arrives, it looks right, and it is trusted. DNSSEC is the mechanism that adds proof.

What DNSSEC actually protects against

Without DNSSEC, an attacker positioned between your customer and the DNS system can substitute a different answer. Your customer types your domain, their computer receives a forged reply pointing somewhere else, and they arrive at a site that is not yours.

The important part: their browser shows no warning. There is no certificate error and no “suspicious site” screen, because as far as the browser is concerned it went exactly where DNS told it to go. The same applies to mail: a forged DNS answer can redirect where your incoming email is delivered.

DNSSEC closes this by signing DNS records cryptographically. Each answer arrives with a signature that a validating resolver checks. If the signature does not match, the answer is discarded rather than used.

The chain of trust

DNSSEC works as a chain, each link vouching for the next.

The root zone signs a record vouching for .com. The .com registry signs a record vouching for yourcompany.com. Your DNS provider signs the individual records inside your zone.

The link between your registry and your DNS provider is a DS record (Delegation Signer). It is a fingerprint of your signing key, published at the registry rather than in your own zone. A resolver walks the chain from the root down. If any link is missing or wrong, validation fails and the resolver returns nothing rather than an unverified answer.

That last sentence is the whole reason order matters.

Why the wrong order takes your domain offline

Enabling DNSSEC involves two separate systems: your DNS provider, which signs the zone, and your registrar, which publishes the DS record at the registry.

If those two ever disagree, validating resolvers conclude the answers are forged and refuse to return them. Your domain stops resolving. Website and email, both gone, everywhere that validates.

The two ways to get it wrong:

• DS record published before the zone is signed. The registry says “this domain is signed, here is the key to check it with,” resolvers go looking for signatures, find none, and fail.
• Zone signed, DS record never published. Less dramatic. The zone is signed but nothing at the registry vouches for it, so resolvers cannot validate and DNSSEC provides no protection. You have the complexity without the benefit.

The correct sequence is: sign the zone at your DNS provider first, confirm it has propagated, then publish the DS record at the registrar. Confirm each step before starting the next.

The same care applies in reverse. Turning DNSSEC off means removing the DS record at the registry first, waiting for that to propagate, and only then unsigning the zone. Doing it the other way around causes exactly the same outage.

And when you change DNS providers on a DNSSEC-signed domain, the signing keys change. Migrate without handling the DS record and the domain goes dark mid-transfer. This is the most common way we see a DNSSEC outage happen in practice: not from enabling it, but from moving providers afterwards and forgetting it is on.

Is it hard, or expensive?

Neither, which is the frustrating part.

At Cloudflare and most modern DNS providers, signing the zone is a single toggle. Most registrars accept the DS record through their control panel, and many now do the handoff automatically when both sides are with the same company. It is free. There is no ongoing cost and no licence.

The complexity is entirely in the sequencing, and in knowing what to check between each step. That is judgement rather than effort, and it is exactly the sort of thing that gets skipped when somebody is working through a migration checklist at speed.

What DNSSEC does not do

It is worth being precise, because DNSSEC is sometimes oversold.

• It does not encrypt DNS. Anyone watching still sees which domains are being looked up. Encryption is what DNS-over-HTTPS and DNS-over-TLS do, and they are a different thing solving a different problem.
• It does not stop email spoofing. That is SPF, DKIM and DMARC. See SPF, DKIM and DMARC explained.
• It does not protect you if your DNS account is compromised. An attacker who logs into your DNS provider changes the records legitimately, and DNSSEC obligingly signs the new ones.
• It only helps where resolvers validate. Most large public resolvers do, and coverage is good, but it is not universal.

What it does is guarantee that the answer a validating resolver gives came from you and was not altered on the way. That is a narrow guarantee, and a valuable one.

Check whether you have it

The free domain security checker tells you in about twenty seconds whether your domain is DNSSEC-signed, by looking for the DS record at the registry. It also checks your CAA record, which is the other free, quick, almost-never-configured DNS control worth having. See the CAA record explained for that one.

If it comes back unsigned and you would rather not sequence the change yourself, our Cloudflare, DNSSEC and WAF engagement does it registry-side first, with the rollback path documented before anything is switched on.