How to enable DNSSEC on Cloudflare

You’ve found the DNSSEC switch at Cloudflare and want to know whether pressing it finishes the job or can take the domain offline. That depends on where the two halves happen: the DNS host signs the zone and produces a DS record; the registrar lodges it in the parent zone. Until both are done, no resolver validates anything.

Cloudflare is the DNS host in this pair, not the registrar. It signs the zone and publishes the DNSKEY plus a DS record for the reader to carry to the registrar, and it leaves the registrar step to whichever company the domain is bought and renewed through.

What a signed zone proves

DNSSEC attaches signatures to the answers your DNS hands out, so a resolver can confirm that the address it got for your domain came from your zone and wasn’t changed on the way. It says nothing about what’s running at that address, and nothing about email: a signed domain can still have its name forged on a message, because the controls for that are SPF, DKIM and DMARC, covered on the DMARC page.

The signing happens wherever the zone is served, so it’s a DNS host job, and the host publishes the public key in the zone as a DNSKEY record. The DS record is a hash of that key, and it belongs one level up, in the parent zone (.com, .org, .co.uk, whichever your domain sits under), where a resolver picks up the chain of trust before it asks your nameservers anything.

Only the registrar can place a record there, so the DS goes through the registrar’s account, which may or may not belong to the company running your DNS. Of the 316,600,902 domains carrying a grade or counted dead in the September 2026 census, 21,732,692 (6.9%) are signed and validate, and 173,606 (0.05%) are signed and broken, meaning a DS record is lodged and the signatures in the zone don’t match it. The order below keeps you out of the second group.

Confirm who answers DNS before you touch anything

Cloudflare’s DNS is only live once the domain’s nameservers point at the Cloudflare nameservers shown in the dashboard. Open the domain in Cloudflare and check the Overview page to confirm Cloudflare is active. If the nameservers point elsewhere, DNSSEC has to be enabled at whichever provider runs DNS instead, not here.

The steps run in the order that can’t break the domain, and each carries its own wait; this one has none. What it decides is which steps happen inside Cloudflare and which happen in another account. Skip it and you can end up signing a zone no resolver is querying, or lodging a DS for a key the live nameservers aren’t using.

Switch DNSSEC on

Sign in to Cloudflare and select the domain from the account list.
In the left-hand menu, go to DNS, then Settings.
On older dashboards, look for a DNSSEC section shown directly under DNS instead.
Find DNSSEC on that screen and click Enable DNSSEC.
Leave the panel open once it appears, since the values on it have to be copied across to the registrar.
Read off Key Tag, Algorithm, Digest Type and Digest from the panel, plus the ready-made single-line DS record it also shows.
Copy and paste the Digest value rather than retyping it, since a single wrong character breaks the match.
After the registrar has accepted the DS record, return to this same DNSSEC panel in Cloudflare and check the status again.

Cloudflare signs the zone and publishes the DNSKEY and DS record values for the reader to copy, but it cannot lodge the DS record into the parent zone itself. That half happens at the registrar, in a separate account.

Signatures and the DNSKEY have to be live on the nameservers before a DS pointing at them is lodged anywhere, because once the DS lands in the parent zone, validating resolvers demand signatures that match it. In a two-company setup this is the point to stop, wait for the DNS host to show the zone as signed, and only then carry the DS across.

The DS record, value by value

A DS record carries four values, shown together on one panel once signing is on. The key tag is a number identifying which DNSKEY the record refers to. The algorithm names the signing algorithm the host chose: 13 is ECDSA P-256 with SHA-256, what most hosts generate today; 8 is RSA with SHA-256, still valid; 5 and 7 are older RSA variants a fresh setup shouldn’t use.

The digest type says how the key was hashed: 2 is SHA-256, the one to publish; 4 is SHA-384, which some hosts offer alongside it; 1 is SHA-1, which registries are removing. The digest is the fingerprint itself, 64 hexadecimal characters for SHA-256, with no spaces. Here is what the panel gives you to carry across:

Key Tag: [the number Cloudflare shows]
Algorithm: 13 (ECDSA P-256 SHA-256)
Digest Type: 2 (SHA-256)
Digest: [the long hexadecimal string Cloudflare shows]

Lodge the DS values exactly as the host displays them. If the host offers two digest types for the same key, the SHA-256 one alone is enough. There’s nothing to tighten afterwards: the strength of the record is fixed by the algorithm the host signs with, and a host that manages the keys rolls them and refreshes the DS itself.

Where each value goes depends on the registrar’s form. Cloudflare generates every field itself rather than asking the reader to type a record: Key Tag is a number, Algorithm is usually 13, Digest Type is usually 2, and Digest is a long hexadecimal string, all shown together with a ready-made single-line DS record. There is no host or name field to fill in on this screen, since the DS record gets lodged at the registrar rather than published inside Cloudflare’s own DNS records.

Paste every value rather than typing it. A digest with one wrong character produces a DS that no key in the zone matches, and a validating resolver can’t tell that apart from a hijacked zone, so it refuses the whole domain. Match the algorithm and digest type numbers to the panel, whatever the registrar’s form offers as a default.

A few things trip people at Cloudflare in particular.

Clicking Enable DNSSEC in Cloudflare does nothing on its own. The DS record still has to be lodged at the registrar, and stopping after this click is the most common reason status stays pending.
If Cloudflare is also the registrar for this domain, the DS step is handled internally and there may be no separate registrar form to fill in, but the DNSSEC status still needs to be checked until it reads active.
Never delete the DS record at the registrar while Cloudflare is still the signing host, since the parent zone will keep expecting signatures that no longer match.
Before moving DNS away from Cloudflare, disable DNSSEC and clear the DS record at the registrar first, then move DNS. Doing this out of order is what breaks the domain.
A DS record at the registrar that does not match what Cloudflare is signing with is its own failure mode, distinct from forgetting to lodge it at all.

Wait, then check the chain

Two waits stack here, and they aren’t the same length. Cloudflare’s DNSSEC status moves to active only once the registrar has accepted the DS record, and that confirmation is not instant.

The parent zone is the slower one. The registry publishes the DS on its own schedule, and any resolver that looked your domain up recently keeps the old answer, with no DS in it, until the parent’s TTL runs out, which can be up to a day. During that window one network can show the domain validating while another shows it unsigned, and both are reporting what they’ve cached.

Once that day has passed, run the free scan against the domain. It validates the way a resolver does and reports each link separately: whether a DS is published in the parent, whether it matches a DNSKEY in the zone, and whether the signatures verify.

Return to the DNSSEC panel under DNS, then Settings in Cloudflare and check whether the status has moved from pending to active.

To see the raw answer, ask a validating resolver with dig:

dig +dnssec yourdomain.com A

Read the flags on the header line. ad means the resolver validated the chain and it held. A normal answer with no ad means the resolver saw the domain as unsigned, so after the wait the DS hasn’t reached the parent zone or was never lodged. SERVFAIL means the chain is there and broken, and the DNSSEC SERVFAIL page walks through which link.

Broken is worse than unsigned. Validating resolvers, including the large public ones, drop the domain for their users while everyone else still reaches it, so the outage looks intermittent and gets blamed on hosting.

Before you move DNS or turn signing off

The step that catches people comes months later, when the domain moves to a new DNS host or signing gets switched off and the DS record stays behind in the parent zone. From then on validating resolvers demand signatures the new nameservers aren’t producing, and the domain returns SERVFAIL for their users until someone removes the DS.

So the teardown runs in reverse. Remove the DS record at the registrar first, wait out the parent’s TTL so no resolver still holds a copy, and only then switch signing off or change the nameservers. A domain with no DS and a signed zone is treated as unsigned, which is safe; a domain with a DS and no signatures is treated as forged, which is the outage.

The other habit is signing in one place. If the DNS host already signs the zone, its DS goes to the registrar and the registrar’s own signing switch stays off; two signers means two keys and one DS, and resolvers refuse whichever half doesn’t match. The DNS page covers the other records in the same zone.

Before you log out of the registrar, write down where the DS is lodged and the key tag it carries, next to the renewal date, with “remove the DS first” beside it. That note is what stops the domain going dark the day someone changes the nameservers.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.