DNSSEC When Moving a Blog's DNS: Remove the DS Record Before the Nameservers Change

DNSSEC can only break a blog migration at one moment: when the domain's nameservers change. Everything else about a host move leaves it alone.

Here is the failure. Your registrar holds a DS record that tells validating resolvers which key should be signing your zone. Move the zone to a new DNS provider while that DS record still describes the old provider's key, and resolvers like 1.1.1.1, 8.8.8.8 and Quad9 answer with SERVFAIL instead of an IP address. The blog disappears for anyone behind a validating resolver and keeps working for everyone else. So it can look fine on your laptop and be down for half your readers, which is the worst kind of outage to debug.

The safe order is short: remove the DS record at the registrar, wait out its TTL, change the nameservers, then turn on DNSSEC at the new provider and add its DS record. The rest of this post is how to tell whether it applies to you, three queries that show the state of the chain with nothing but curl, and what to do if you already switched and things broke.

A normal host move doesn't touch DNSSEC

Most host moves are an edit inside your existing zone: a new A record for the apex, a new CNAME for www. The provider that signs your zone signs the edited records too, and the DS record at the registrar still matches because the keys didn't change.

DNSSEC becomes your problem when the nameservers change. That covers moving DNS to Cloudflare or Route 53, switching from your registrar's default nameservers to custom ones, going back the other way, and transferring the domain to a registrar whose DNS you'll use instead. In every one of those, the party signing the zone changes while the DS record at the registry stays where it was.

Check the chain with three queries

Google Public DNS and Cloudflare's 1.1.1.1 both answer DNS queries as JSON over HTTPS. Google's JSON API takes cd=1 to disable DNSSEC validation, and Cloudflare's takes the same parameter. Comparing a normal answer with a cd=1 answer tells you whether DNSSEC is the reason a name doesn't resolve.

# 1. Is there a DS record at the registry?
curl -s 'https://dns.google/resolve?name=example.com&type=DS'

# 2. Does the name resolve with validation on?
curl -s 'https://dns.google/resolve?name=example.com&type=A'

# 3. Does it resolve with validation off?
curl -s 'https://dns.google/resolve?name=example.com&type=A&cd=1'

I ran queries 2 and 3 on October 14, 2026 against dnssec-failed.org, a test domain whose DS record deliberately doesn't match the keys its nameservers publish. With validation on, Google returned:

{"Status":2, "AD":false, "CD":false,
 "Comment":"DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/ ...",
 "extended_dns_errors":[{"info_code":9,"extra_text":"No DNSKEY matches DS RRs of dnssec-failed.org"}]}

With cd=1, the same resolver returned "Status":0 and the A record 96.99.227.255. Cloudflare gave the same pair through https://cloudflare-dns.com/dns-query (send the header accept: application/dns-json), with the reason in its Comment field as EDE(9): DNSKEY Missing. The records exist and the nameservers answer. Validation is the only thing stopping resolution.

DS query	Query 2	Query 3 (cd=1)	What it means
No answer	Status 0	Status 0	DNSSEC is off at the registry. A nameserver change won't trip on it.
Answer present	Status 0, "AD":true	Status 0	The chain validates. Remove the DS record before you change nameservers.
Answer present	Status 2 (SERVFAIL)	Status 0 with an answer	The chain is broken. Fix the DS record, not your A or CNAME records.
Either	Status 2	Status 2	Something other than DNSSEC is failing, usually nameservers that don't answer for the zone.

The extended error code narrows it down further. RFC 8914 defines code 9, DNSKEY Missing, as "A DS record existed at a parent, but no supported matching DNSKEY record could be found for the child". That is exactly what a DS record left over from the old provider produces. Code 10, RRSIGs Missing, means signatures were expected and none came back, which fits a new provider that isn't signing the zone yet. Cloudflare lists the codes 1.1.1.1 returns on its Extended DNS Error codes page. If you want a picture of the whole chain, DNSViz and Verisign's DNSSEC Analyzer both take a domain and show where it breaks.

Look at the TTL on the DS answer too, because it decides how long the move takes. On the same day, the DS record for cloudflare.com came back from 1.1.1.1 with a TTL of 86400 seconds (one day) and from Google with 7212, which is just the time left in Google's cache. A fresh answer shows the registry's full value. A cached one shows what remains.

The order that works when DNS moves to a new provider

Cloudflare's DNSSEC docs and Route 53's guide to migrating a domain that's in use describe the same sequence. Route 53 states the constraint plainly: "You can't have DNSSEC signing enabled across two providers at the same time."

1. Recreate every record at the new provider: the blog's A and CNAME records, MX for email, and any TXT verification records. Leave DNSSEC off there for now.
2. Remove the DS record at your registrar, and leave signing on at the old provider. Route 53's disable procedure warns that "some registrars have scheduled DS removal, for example once a day", so confirm it's gone by asking the registry's own nameserver, for example dig +norec DS example.com @a.gtld-servers.net for a .com.
3. Wait out the DS TTL. Cloudflare says it is commonly 24 to 48 hours for most TLDs, and its troubleshooting page says to wait at least 1.5 times the TTL: "If the DS TTL is 24 hours, wait 36 hours."
4. Change the nameservers at the registrar and wait for the old NS TTL. Route 53 notes the NS record's typical TTL is two days unless you lowered it beforehand.
5. Turn on DNSSEC at the new provider and add its DS record at the registrar. Cloudflare Registrar adds the DS record itself, which "can take one to two days", and registrars that read CDS records can pick it up automatically. Everywhere else you paste the key tag, algorithm, digest type and digest by hand.
6. Run the three queries again. Query 2 should now come back with "AD":true.

Between steps 2 and 5 the domain resolves without DNSSEC protection. RFC 6781 calls that window "the only viable operation" when the old and new providers don't cooperate. The way around it is multi-signer DNSSEC from RFC 8901, where both providers' keys are published during the move. Cloudflare supports it as an active migration, but only if the old provider lets you add DNSKEY records at the zone apex. I think for a blog that's overkill... I'd take the unsigned day or two over coordinating key imports between two DNS companies, unless the old provider already documents multi-signer support.

What registrars do on their own when you change nameservers

Some registrars handle part of this for you, and their help pages differ in ways that matter mid-move. These are from each registrar's docs as of October 14, 2026.

Registrar	Documented behavior
Squarespace Domains	DNSSEC is "automatically enabled" on supported TLDs and "automatically disabled if you switch to using custom nameservers" (source). You can add one DS record for custom nameservers.
Namecheap	Automatic on BasicDNS and PremiumDNS (source). With custom DNS you manage DS records yourself, and turning DNSSEC back on re-activates "the records you previously configured" (source).
Porkbun	Recommends deleting DNSSEC records before transferring a domain in, then turning on Porkbun's DNSSEC or adding your own afterward (source).
Cloudflare Registrar	Publishes the DS record automatically from the zone's CDS records. "There is currently no way to manually control the exact timing of DS publication" (source).

Namecheap is the one that bites. Switch to custom nameservers, re-enable DNSSEC, and the old DS values come back, describing keys the new provider doesn't have. Replace them with the new provider's values before you save. Squarespace disables DNSSEC as part of the nameserver change itself, so a resolver that cached the DS record earlier can still fail until that cache expires. If your registrar lets you remove the DS record as a separate step, do it a day or two ahead.

Already switched and getting SERVFAIL

Go to the registrar and either delete the DS record or replace it with the one your new provider shows. Deleting is quicker to get right, and you can add the new DS record once the domain resolves. Google's troubleshooting page gives the same fix: "ask your domain registrar to remove stale DS records."

Resolvers that cached the old DS record keep failing until its TTL runs out, so some readers can see the error for up to a day after the fix. Cloudflare's purge cache tool and Google's flush cache page each clear one resolver's cache for a name you enter. That helps readers on those two resolvers and does nothing for an ISP's resolver. Don't touch your A and CNAME records while you wait. They aren't the problem, and editing them adds a second unknown.

A broken chain also stops your new host from getting a certificate. Under CA/Browser Forum ballot SC-085v2, CAs have had to validate DNSSEC on CAA lookups since March 15, 2026, and the Baseline Requirements say a validation error such as SERVFAIL "MUST NOT be treated as permission to issue." So a host that issues HTTPS automatically can sit at "pending" until the DS record is fixed, with no useful error. I wrote up the rest of that lookup in CAA records and your blog host.

I went through all of this while wiring custom domains on JustBlogged. If a domain is stuck on "pending" after a nameserver change, those three queries tell you in a minute whether DNSSEC is the reason