Change a DS Record without SERVFAIL

Remove DNSSEC, move the signing to another provider, or roll a key-signing key. The order of the steps decides whether your domain keeps resolving.

Why the order matters

The DS record at your registrar tells validating resolvers which key must sign your zone. A resolver that has the DS but cannot find a matching DNSKEY in your zone does not fall back to "unsigned". It rejects the answer and returns SERVFAIL. For everyone behind that resolver, your domain is gone: web, mail, everything.

Two rules prevent this:

  • Never remove the key before the DS. As long as any DS for a key is published or cached, that key must stay in the zone.
  • Wait for the TTL. Resolvers keep a DS as long as its TTL allows, even after you deleted it at the registrar. Many registries also publish changes only every few minutes or hours.

Find out how long to wait

Ask a nameserver of the parent zone directly. For a .ch domain, that is one of the .ch servers:

terminal
# list the parent's nameservers
$ dig +short NS ch.
 
# ask one of them for your DS; the second column is the TTL in seconds
$ dig +norecurse +noall +answer DS example.ch @<parent nameserver>

When the parent no longer returns your DS, start the clock: wait at least that TTL, and add some margin. If the TTL is one day, wait a little more than a day.

Case 1: Turn DNSSEC off

  1. Delete the DS record at your registrar.
  2. Check the parent nameserver until the DS is gone.
  3. Wait at least the DS TTL.
  4. Only now turn signing off. On hiddenprimary.ch, use the DNSSEC tab or the API:
terminal
$ curl -X DELETE https://hiddenprimary.ch/v1/zones/1/dnssec \
  -H "Authorization: Bearer $HP_KEY"

If you do it the other way round, the DS points to keys that no longer exist. We report this state as Orphaned DS on the DNSSEC tab.

Case 2: Move the signing to a different signer

This covers moving from another DNS provider to us, moving from signing on your own primary to signing on the secondary, and the reverse. The old and the new signer use different keys, so the DS has to change.

The simplest safe way goes through a short unsigned period. The zone keeps resolving the whole time; it is only without DNSSEC protection for a while.

  1. Remove the old DS at your registrar. Keep the old signer running.
  2. Wait until the parent no longer returns the DS, plus the DS TTL.
  3. Switch the signer. For example: turn signing off on your primary, or move the delegation to the new provider.
  4. Turn on signing at the new signer.
  5. Publish the new DS at your registrar.

A move without any unsigned period is possible, but both signers then have to publish each other's keys for a while (the multi-signer model, RFC 8901). Both providers must support that.

From your own signing to ours

While your primary signs the zone, we serve your signatures unchanged, and we refuse to add our own. After step 3, your primary serves the zone without DNSKEY records. We see that on the next transfer and treat the zone as unsigned. Then turn on DNSSEC in the portal and publish the DS it shows.

Case 3: Roll the key-signing key

A key-signing key (KSK) rollover keeps the same signer but introduces a new key. Here the DS changes without any unsigned period, if you keep both DS records for a while:

  1. Start the rollover. The new KSK is published next to the old one.
  2. Add the DS for the new KSK at your registrar. Keep the old DS.
  3. Wait until the parent returns both DS records, plus the DS TTL.
  4. Let the old KSK retire.
  5. Remove the old DS only after the old key is gone from your zone.

On hiddenprimary.ch, steps 3 and 4 happen automatically: once public resolvers have shown a DS for both keys for 48 hours, we retire the old KSK. The DNSSEC tab lists a DS record for every KSK that is currently in the zone. While the old DS is still in that list, keep it at your registrar.

Check the result

After every step, check from outside that the chain of trust is valid:

terminal
# validates the whole chain itself; look for "; fully validated"
$ delv SOA example.ch
 
# SERVFAIL without +cd, but an answer with it: DNSSEC is broken
$ dig SOA example.ch
$ dig +cd SOA example.ch

We also check the DS against the key we sign with every hour, and show the result on the DNSSEC tab: DS mismatch and Orphaned DS mean validating resolvers fail your zone right now. With webhooks, the dnssec_ds_alert event tells you at once.

Next Steps