How to change DNS provider with DNSSEC enabled

Moving a domain to a new DNS provider is routine: copy the records, change the nameservers at the registrar, wait. With DNSSEC turned on, the same routine can take the whole domain offline for every user behind a validating resolver, and it can stay offline for a day or more after you notice. The fix is not complicated, but the order of steps is not optional.

1 Why the wrong order breaks your domain

DNSSEC links your zone to its parent (.com, .eu, .pl) with a DS record. The DS record is a fingerprint of your zone's signing key, published by the registry through your registrar. A validating resolver follows the chain: the parent says "this zone is signed with key X", the zone's answers must be signed with key X, otherwise the answer is treated as forged.

Every DNS provider signs your zone with its own keys. Your old provider's private keys never leave it, so the new provider cannot produce signatures that match the old DS record. If you switch nameservers while that DS is still published:

• the parent still says "expect key X",
• the new nameservers answer with no signatures, or with signatures from key Y,
• validating resolvers return SERVFAIL for every name in the domain.

Non-validating resolvers keep working, which makes this failure confusing: it works for some people and not for others. Large public resolvers such as Google Public DNS, Cloudflare 1.1.1.1 and Quad9 validate DNSSEC, and so do many internet providers.

2 The safe path: go unsigned, move, sign again

This works with any pair of providers. The domain is unsigned for a while (typically one to a few days), which means no DNSSEC protection during that window, but it keeps resolving for everyone.

2.1 Step 1: check where you start

dig +short NS example.com          # current nameservers
dig +short DS example.com          # DS records published by the parent
dig +noall +answer DS example.com  # same, with the TTL resolvers will cache it for

Write down the DS TTL. Many registries use one day, some use less or more.

2.2 Step 2: lower TTLs at the old provider

Lower the TTL of the records that matter (and of the NS records inside the zone, if the provider lets you) to 300 seconds, at least one old TTL before you move. This shortens how long resolvers keep old answers after the switch.

2.3 Step 3: remove the DS record at your registrar

In the registrar's DNSSEC settings, delete the DS record (some registrars call it "disable DNSSEC" even though the zone itself stays signed at the provider). Check that the parent no longer publishes it:

dig +short DS example.com @a.gtld-servers.net   # ask a .com registry server directly; use your TLD's servers
dig +short DS example.com @1.1.1.1              # a resolver may still show the cached DS until its TTL runs out

Then wait at least the DS TTL from step 1, plus a margin. Until every cached DS has expired, some resolvers still expect the old key. This wait is the step people skip.

2.4 Step 4: copy the zone and change nameservers

Export the zone from the old provider in BIND format and import it at the new one. Leave out DNSSEC records (DNSKEY, RRSIG, NSEC, NSEC3): the new provider signs the zone with its own keys. Compare a few answers from both sets of nameservers, then change the nameservers at the registrar.

dig +short www.example.com A @old-ns1.example.net
dig +short www.example.com A @ns1.primedns.net

Keep the zone active at the old provider until the NS change has expired from caches. NS records at the parent commonly have a TTL of one to two days.

2.5 Step 5: sign at the new provider and publish the new DS

Enable DNSSEC at the new provider, copy the DS record it shows you (use the SHA-256 digest, digest type 2) and add it at the registrar. Then check the chain:

dig +dnssec +noall +answer example.com SOA @ns1.primedns.net   # RRSIG present: the zone is signed
dig +short DS example.com @a.gtld-servers.net                  # the new DS is at the parent
delv @1.1.1.1 example.com A                                    # "fully validated" means the chain is complete

Visual checks like DNSViz and the Verisign DNSSEC Analyzer show the whole chain and point at the broken link if there is one.

3 The multi-signer path: move without going unsigned

RFC 8901 describes running two providers that both sign the zone, each with its own keys. Each provider publishes the other's zone-signing key in its DNSKEY set, and the parent publishes DS records for both providers' key-signing keys. Any resolver can then validate answers from either set of nameservers, so the nameserver change happens with DNSSEC on the whole time.

It needs both providers to let you import a foreign DNSKEY into the signed zone, usually through their API, and it needs careful coordination of key rollovers while both are active. It is worth it for domains where an unsigned window is not acceptable (banks, government, high-value targets). For most domains the unsigned path is simpler and safe.

4 When it already broke: is it DNSSEC?

If a domain returns SERVFAIL after a move, ask the same resolver again with checking disabled (the CD flag). If the answer comes back with +cd and fails without it, the problem is DNSSEC validation, almost always a stale DS record:

dig example.com A @1.1.1.1        # status: SERVFAIL
dig +cd example.com A @1.1.1.1    # status: NOERROR, so validation is what fails

The fastest repair is to remove the DS record at the registrar. Users recover as the cached DS expires, which is why the DS TTL from step 1 matters even in an emergency.

5 How PrimeDNS handles this

• Import your zone in BIND format from the old provider in one step; SOA and the zone's own NS records are managed by PrimeDNS. See the zone migration guide.
• DNSSEC in one click once the nameservers point at PrimeDNS. Zones are signed with a single combined key, ECDSA P-256 by default (P-384 and Ed25519 are available), with NSEC3 and a per-zone salt.
• The DS record is shown ready to copy, with SHA-1 digests left out as RFC 8624 recommends.
• For .pl domains registered through PrimeDNS, the DS record is sent to the registry automatically when you enable DNSSEC and removed when you disable it. For other domains you add it at your registrar.
• Every DNSSEC change is in the Audit Log, and the Propagate button next to each record shows when public resolvers return the new answers.

When moving a signed domain away from PrimeDNS, follow the same order: remove the DS at your registrar first (automatic for .pl domains registered with us when you disable DNSSEC; for other domains the panel reminds you to remove the DS at your registrar before it turns signing off), wait for its TTL, then move. The unsigned path above is the one to use with PrimeDNS.

Information about other providers is based on their public documentation as of October 2026. Product names and trademarks belong to their owners. Spotted something out of date? Write to This email address is being protected from spambots. You need JavaScript enabled to view it..