Guides

The DS record that takes your whole domain dark

Change nameservers with DNSSEC still signed at the registry and every validating resolver returns SERVFAIL — web and mail, globally. Verified on a domain nobody had configured.

This is the failure a one-stop mail provider exists to prevent, because it is caused entirely by two companies not talking to each other: a registrar that signed your domain and a DNS host that cannot serve the signature.

Why a checker tells you the wrong thing here, and Yowl doesn’t

A domain in this state answers nothing. So every setup wizard, every “check my DNS” website and every records page you paste your domain into reports the same thing: your records are missing. They are not. They are unreachable, which is a completely different problem. You are sent to your DNS host to re-add records that are already there, when the repair is at the registrar.

Yowl’s domain report has a fourth state for exactly this. Every record comes back as ok, missing, different or unknown — and unknown means the lookup itself failed. A record we could not read never goes on your to-do list, because “I could not check” is not “it is broken”, and a confident instruction built on a failed lookup is how you get talked into breaking a working zone.

“nothing about this domain is answering — go and look at the registry”, which is the sentence that saves the day.

Sequencing it is the product

The safe order at the bottom of this page is four steps, and the whole difficulty is that step one is at a company that is not your DNS host, and steps two and three cannot be hurried. That is a sequencing problem, and sequencing is exactly what gets dropped when a migration is spread across five dashboards and two people.

Yowl is built to hold the whole lifecycle — the registration, the nameservers, the mail records, the cutover, the DMARC ladder — in one place, which means the ordering can be enforced rather than documented. Ask your agent to move a domain and the DS question is answered before anything is changed: it reads the parent registry directly, tells you the domain is signed, and stops. It does not discover it afterwards.

“Check example.com before we change its nameservers.”

⚠ On some registrars the disable itself is still a human clicking a web UI — see the last section. Thats a registrar specific check you must do.

What actually happens

Of all the ways a domain migration can go wrong, this is the one that takes everything at once. Not degraded, not slow, not mail-only — the domain stops resolving anywhere, for web and mail alike, and no change at the new DNS host can repair it.

It happens when you move nameservers while DNSSEC is still signed at the registry. And the reason people walk into it is that they never turned DNSSEC on.

What is DS

DNSSEC signs a zone’s answers. The DS — Delegation Signer — is a fingerprint of the signing key, published one level up: in the TLD registry (.io, .co.uk), put there by your registrar. It is the parent saying “answers for this domain are signed, and here is the key that signs them.”

A validating resolver that sees a DS then refuses any unsigned answer for that domain. That is the entire point of it — an unsigned answer for a signed zone is what an attack looks like.

You move the nameservers to a host that serves unsigned answers, while the registry still promises signed ones. Resolvers read the mismatch as an attack in progress and return SERVFAIL rather than the record. Nothing resolves, not even dig.

You may already be signed

The assumption that sinks people is “the domain is brand new, I set nothing up, that record cannot be there.” That is exactly backwards on registrars which sign by default on their own nameservers.

Measured on yowl.io, registered on 24 September 2026 at Spaceship and touched by nobody, hours after purchase:

dig +short DS yowl.io @a0.nic.io
# 42547 13 2 9B813CBE419B292656CBBC45A077A0B54A2167F10F356B1D541AB78AF8BAE2D4

dig +short DNSKEY yowl.io @launch1.spaceship.net   # 256 (ZSK) + 257 (KSK), both present
dig +dnssec SOA   yowl.io @launch1.spaceship.net   # RRSIG present — genuinely signed

It is a security default on that registrar’s own nameservers, no opt-out at purchase. Several registrars behave this way now, which is good for the web and a trap on moving day.

⛔ Do not assume switching nameservers withdraws it

This is the part we got wrong, and got away with once.

A sibling domain of ours moved to custom nameservers and the registrar dropped the DS by itself. The registrar’s own custom-nameserver documentation warns that hosting and email connections terminate and that records go inactive, and never mentions the DS at all. Cloudflare’s guidance for domains at that registrar is to have the registrar remove the DNSSEC records first, and general registrar practice is the same: disable DNSSEC and confirm the DS is gone from the parent before switching, or pre-publish the new host’s DS.

Check the registry, not the dashboard.

The dashboard is the wrong place to look — ask the registry’s own nameservers:

# .io
dig +short DS yowl.io @a0.nic.io

# generic: find the TLD's nameservers, then ask one
dig +short NS io.
dig +short DS example.co.za @coza1.dnsnode.net

Empty output is what safe looks like. Anything returned is a promise the new host has to keep, and it can’t.

The safe order

  1. At the registrar, disable DNSSEC for the domain.
  2. Confirm from the parent that the DS is gone — the query above, empty. Allow for the registry’s TTL before trusting it; this is not instant and there is no way to speed it up.
  3. Then change the nameservers.
  4. Optionally re-enable DNSSEC at the new host afterwards, which publishes a new DS through the registrar.

⚠ Reverse steps 1 and 3 and the repair is not at the new host. It is at the registrar, and you then wait out the TTL with the domain dark. If the registrar account itself recovers through an address on that domain, you have just lost the mailbox you need to fix it — which is the other half of this problem: migrating without locking yourself out.

One more trap

We went looking for an API to clear a DS on our registrar and there is not one. Its published scope list covers domains, contacts, DNS records, transfers and billing — there is no DNSSEC scope and no DS endpoint.

That matters if you script your DNS, and it matters more if you have delegated the migration to something automated.

Connect a domain to Yowl →