Publishing a DS record before the zone is signed takes the whole domain down

Most DNS mistakes are forgiving. Point an A record at the wrong address and the site is wrong but reachable; you fix the record and it comes back as caches expire. DNSSEC is not like that. It fails closed, and it fails closed everywhere at once.

What the DS record actually does

DNSSEC splits responsibility between two parties.

Your zone holds the keys and the signatures. Every answer it gives is accompanied by an RRSIG record, and the public half of the signing key is published as a DNSKEY.

The parent zone — .com, .co.uk, whoever is above you — holds a DS record. A DS is a hash of your key, and it is a statement to the entire internet: the zone below me is signed, and this is the key it signs with. If you ask it something and the answer is not signed with this key, the answer is a lie.

That last clause is the whole problem. A DS record is not a request to try DNSSEC. It is an instruction to reject anything that fails validation.

The failure mode

Publish a DS at the registry for a zone that is not actually serving signatures, and every validating resolver in the world does exactly what you told it to: it asks your nameserver, gets an unsigned answer, compares that against the DS saying the answer must be signed, and concludes the response has been tampered with.

It does not fall back. It does not return the record with a warning. It returns SERVFAIL.

For the person trying to reach you, this looks worse than an outage. Their browser says the site cannot be found. Their mail bounces with a delivery failure that names your domain as nonexistent. Your monitoring may well be fine, because the machine is up and your own resolver may not validate.

And the recovery is slow in a way normal DNS problems are not. Removing the DS means a change at the registry, through your registrar, and that has its own TTL — commonly a day. You cannot fix it by editing your zone, because your zone is not where the wrong information lives.

The order that works

1. Sign the zone. Generate keys, sign, and publish the DNSKEY and RRSIG records.
2. Confirm every nameserver is serving signatures. Not one. Every single one listed in your NS records. Query each of them directly with the DO bit set and check that signatures come back.
3. Only then publish the DS at the parent.

Step two is the one people skip, and it is the one that matters. Nameservers are added, rebuilt, and occasionally restored from a configuration that predates signing. A zone that is signed on three of four nameservers is not signed. It is a domain that works for most people and fails, unpredictably and permanently, for the quarter of the internet that happens to ask the fourth.

Removing DNSSEC has a mirror-image rule: take the DS out of the parent first, wait for it to expire from caches, and only then stop signing. The invariant in both directions is the same — never let a DS exist without signatures behind it.

The automation rule

If you are building this into a control plane, there is one design decision that decides whether the bug is possible at all.

The tempting API is an enable_dnssec call that signs the zone and returns the DS record, ready to hand to the registrar. It reads well and it is wrong, because it returns the DS at the moment signing was requested, not the moment signing was observed on every nameserver. The caller takes that DS, pushes it to the registry, and the race is on.

The safer shape is to refuse to hand out the DS at all until a separate status check has asked every nameserver over the wire, with the DO bit, and seen signatures come back. Enabling returns nothing but an acknowledgement. The DS becomes available only once it is true.

That turns a guarantee that depends on everybody remembering into one the system enforces, which is the only kind that survives contact with a busy afternoon. A guard is only worth having if the things downstream of it actually respect it — so the call that publishes the DS to the registrar should read the same flag, and decline when it is not set.

What to check right now

If you have DNSSEC enabled anywhere, it is worth ten minutes:

• Ask each of your nameservers directly, not your local resolver, and confirm each returns RRSIG records.
• Confirm the key in the parent's DS matches the DNSKEY your zone is currently publishing. A key rotation that completed at the zone and not at the registry is the same outage on a delay.
• Check what your monitoring actually does. If it resolves through a non-validating resolver, it will report a fully broken domain as healthy.

DNSSEC is worth having. It just has no tolerance for being half-configured, and the penalty is not a degraded service — it is the domain.