Why a DS mistake is an outage, not a weakness
DNSSEC trusts in a chain: the parent zone (for example the extension's zone) publishes a DS record, a fingerprint of the client zone's signing key, and validating resolvers compare that fingerprint with the keys the zone actually publishes. If the fingerprint matches no key any more, the resolver cannot prove that the answers are authentic and refuses to answer: the user gets a SERVFAIL.
This is what makes the mistake treacherous. The domain keeps answering on a resolver that does not validate, so a quick test from a workstation or a corporate network can look fine, while users behind a validating public resolver resolve nothing. An orphan DS does not lower security: it cuts the domain off. The rest of this guide is about never creating one, and knowing how to get out of one.
Who does what: DNS operator, registrar, registry
Three parties are involved, and confusion between them causes most incidents. The DNS operator hosts the zone and holds the keys: it signs and publishes the DNSKEY and RRSIG records. The registrar is the commercial interface where the holder manages the name, and it passes the DS record on to the registry. The registry maintains the parent zone and publishes the DS.
The DS is therefore never created at the registrar alone: it copies information produced by the DNS operator. If the domain is registered at one registrar but its name servers point to another operator, signing is requested from the DNS operator and the DS is entered at the registrar. The general definition of DNSSEC and its role against cache poisoning is assumed known here; the article on the root key change of 11 October 2026, on the resolver side, covers the other end of the chain.
Enable DNSSEC in the right order
Check that the extension and the registrar accept the DS
Before touching the zone, confirm that the registrar offers a DS field for this extension and that the registry accepts the planned algorithm. Not every registry accepts every algorithm: the extension's list is authoritative, not the DNS operator's. Some extensions do not offer DNSSEC at all, by registry rule.
Write the rollback plan before starting
Record the current state: name servers, zone TTLs, absence of a DS. Capture it with
dig NS your-domain.com +shortanddig DS your-domain.com +short. Also write down who can delete the DS at the registrar, and through which channel, if something goes wrong. A rollback that depends on someone unreachable is not a rollback.Sign the zone at the DNS operator
Enable signing in the operator's interface, or with its tools if you run the server yourself. The operator generates the key signing key (KSK) and the zone signing key (ZSK), then publishes the DNSKEY and RRSIG records. At this stage nothing changes for resolvers: without a DS in the parent zone, the zone is signed but not validated, so there is no risk.
Wait for the DNSKEY records and signatures to propagate
Resolvers keep old answers in cache until their TTL ends. Wait at least the longest TTL in the zone before moving on, and check that
dig +dnssec your-domain.com DNSKEYreturns the keys and their signature from each of the name servers.Collect the DS parameters
The DNS operator provides four values: the key tag, the algorithm, the digest type and the digest. Check that they match the published KSK (the flags field is 257) and choose the SHA-256 digest, type 2. Copy and paste them rather than retyping: a single wrong character produces an orphan DS.
Publish the DS at the registrar
Enter the four values in the registrar's DS field. The registry then publishes the DS in the parent zone, with a delay specific to the extension. Until that delay has passed, some resolvers still see the old state: only conclude after verification.
Verify the chain end to end
Query the parent's server, then a validating resolver, then
delv, as detailed in the next section. Keep the rollback plan open until all three checks pass from at least two different validating public resolvers.
Algorithms and digests: what RFC 8624 requires
Scroll the table
| Parameter | Value | Status in RFC 8624 |
|---|---|---|
| ECDSAP256SHA256 signature | 13 | MUST, the usual choice |
| RSASHA256 signature | 8 | MUST |
| ED25519 signature | 15 | RECOMMENDED |
| ED448 and ECDSAP384SHA384 signature | 16 and 14 | MAY |
| RSASHA1 signatures and variants | 5, 7 and 10 | NOT RECOMMENDED |
| DS digest: SHA-256 | 2 | MUST |
| DS digest: SHA-1 and GOST | 1 and 3 | MUST NOT for delegation |
Verify with dig and delv, with real output
Four checks are enough. The first, dig +dnssec your-domain.com DNSKEY, must return two DNSKEY records with flags 256 (ZSK) and 257 (KSK) and an RRSIG. The second, dig DS your-domain.com @<parent server>, queries the parent zone directly and must return a line of the form <key tag> <algorithm> <digest type> <digest>, for example 2371 13 2 <digest> (illustrative values): the key tag must be that of the KSK published by the operator.
The third, dig +dnssec your-domain.com A @1.1.1.1, must show the ad (authenticated data) flag in the flags line, for example flags: qr rd ra ad. The fourth, delv your-domain.com A @1.1.1.1, must print ; fully validated before the answer. A failure looks like this: dig returns status: SERVFAIL, often with EDE 9 DNSKEY Missing, and delv reports resolution failed.
What can block you at the registrar or the registry
- No DS field — the registrar does not offer the entry for this extension, or only by ticket: ask before signing the zone.
- Algorithm refused — the registry accepts only some of the RFC 8624 algorithms; read the extension's list, not the DNS operator's.
- Limited digest — some forms accept only SHA-256; that is the right choice, but you need to know before generating the DS.
- Publication delay — the parent zone is not updated instantly; this delay depends on the extension, so do not test too early.
- Extension without DNSSEC — some extensions do not offer the feature; the domain stays valid but cannot be signed.
- Manual validation — the request goes through a registrar ticket or a contact, which lengthens the rollback: build it into the plan.
Change DNS provider without leaving an orphan DS
This is the case that causes the most outages. The DS stays at the registrar while the name servers change: if the new operator does not sign, or signs with other keys, the old DS matches nothing and validating resolvers answer SERVFAIL. The same incident happens in a zone migration where the old DS is kept.
RFC 6781 distinguishes two cases, depending on whether the old operator cooperates. If it does, the two operators exchange their public keys and publish both sets during the switch, which avoids any unsigned period. If it does not, the RFC concludes that the only viable operation is to let the zone go unsigned: remove the DS, change the name servers, then insert a DS pointing to the newly signed zone. When in doubt, apply the cautious version below, which works in both cases.
Cautious procedure for changing DNS provider
Prepare the zone at the new operator
Recreate every record, without signing or changing name servers. Compare the two zones record by record, for example with
dig @<old server> your-domain.com MX +shortthendig @<new server> your-domain.com MX +short, and likewise for A and TXT.Note the DS TTL
Query
dig DS your-domain.com @<parent server>and note the TTL shown: it is the time during which resolvers may still believe the old DS.Delete the DS at the registrar
Have the DS deleted, then confirm it has gone with the same command on the parent's server. The zone becomes unsigned for resolvers, which is a valid state and causes no outage.
Wait for the DS TTL to expire
Wait at least the duration noted before touching the name servers. Removing keys before the DS has expired from caches recreates exactly the orphan DS you are trying to avoid.
Change the name servers
Edit the NS records at the registrar. Check the switch with
dig NS your-domain.com @<parent server>then test resolution from a validating resolver. The guide on changing name servers details the operation in the client area.Sign at the new operator, then republish the DS
Enable signing, wait for the DNSKEY records to propagate, collect the new parameters and publish the DS as in the initial activation. Finish with the four dig and delv checks.
Key rollovers, CDS and CDNSKEY
Two maintenance operations look alike but do not have the same effect at the registrar. A ZSK rollover requires no action at the registrar, because the DS covers only the KSK. A KSK rollover requires a new DS: RFC 6781 describes the double-signature method in four phases, with a wait of at least the DS TTL before removing the old key. For an algorithm change, the same RFC asks to remove the DS from the parent first, then the DNSKEY and the signatures.
To avoid manual entry, RFC 7344 defines the CDS and CDNSKEY records: the DNS operator publishes the desired DS in the zone and the parent's agent can consume it, after DNSSEC validation. RFC 8078 adds removal, through CDS 0 0 0 0 or CDNSKEY 0 3 0 0. The registry or registrar still decides whether to consume them, and their support depends on the extension. On 13 October 2026, ICANN opened a public consultation on the security and stability assessment of DS automation, open until 23 November 2026. The announcement does not mention CDS or CDNSKEY: automation is neither adopted nor imminent at this stage.
Symptoms, causes and remedies
Scroll the table
| Symptom | Likely cause | Remedy |
|---|---|---|
| SERVFAIL at 1.1.1.1 or 8.8.8.8, normal answer elsewhere | Orphan DS or key missing from the zone | Remove the DS, wait for its TTL, republish a correct DS |
| `EDE: 9 (DNSKEY Missing)` in the dig output | No DNSKEY matches the DS | Compare the DS key tag with the published KSK |
| `delv` answers `resolution failed` | Broken chain of trust | Test with `dig +cd` to confirm the zone answers without validation |
| No `ad` flag but no error | Non-validating resolver or DS not yet published | Query another resolver, wait for the registry delay |
| Outage after a name server change | New operator unsigned, old DS kept | Follow the cautious procedure, starting by removing the DS |
| Expired signatures | Automatic signing stopped at the operator | Restart signing, compare the RRSIG dates |
The rollback plan is written before, not during
Write down the starting state, the command that proves each step and the person who can delete the DS in an emergency. When in doubt, the shortest way out is always the same: delete the DS at the registrar, then wait for its TTL. The zone becomes unsigned but reachable, and you can then diagnose without pressure using dig +cd.
What ServOrbit.com does and does not do
DNSSEC cannot be enabled self-service from the client area. To request it, open a ticket from your client area or write to [email protected]. Support depends on the extension and its registry, particularly for .ma domains. ServOrbit.com does not sign zones for you and does not expose a DS field in the client area: this guide describes the method, not an automatic feature. Managed Cloudflare DNS, presented in the matching activation guide, is mentioned here on one point only: changing name servers on an already signed domain exposes you to the orphan DS. To add or edit records during preparation, the guide on DNS records remains the reference, and the one on outgoing transfers covers a registrar change. Guide provided, no support included.
The official documentation
RFC 6781, DNSSEC operational practices: https://www.rfc-editor.org/rfc/rfc6781.html
RFC 8624, algorithms and digests: https://www.rfc-editor.org/rfc/rfc8624.html
RFC 7344, CDS and CDNSKEY: https://www.rfc-editor.org/rfc/rfc7344.html
RFC 8078, DS management by the child: https://www.rfc-editor.org/rfc/rfc8078.html
ICANN consultation on DS automation: https://www.icann.org/en/announcements/details/icann-seeks-input-on-security-stability-assessment-of-dnssec-ds-automation-13-10-2026-en
Root KSK rollover: https://www.icann.org/resources/pages/ksk-rollover-en
