[{"data":1,"prerenderedAt":237},["ShallowReactive",2],{"seo-verification":3,"blog-enable-dnssec-client-domain-registrar-ds-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-enable-dnssec-client-domain-registrar-ds-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":183,"ctaBody":184,"ctaButton":185,"ctaUrl":186,"relatedPosts":187},529,"enable-dnssec-client-domain-registrar-ds",{"fr":12,"en":10,"ar":13,"es":14},"activer-dnssec-domaine-client-registrar","تفعيل-dnssec-نطاق-العميل-سجل-ds-registrar","activar-dnssec-dominio-cliente-registrador-ds","Enable DNSSEC on a client's domain without an orphan DS","Enable DNSSEC in the right order: sign the zone, publish the DS at the registrar, verify with dig and delv, and change DNS provider without an orphan DS.",11,0,false,"2026-10-29T00:00:00+00:00","2026-10-29T15:45:55+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Factiver-dnssec-domaine-client-registrar-poster.svg","Enabling DNSSEC on a client's domain takes two steps: sign the zone at the DNS operator, then publish the DS record at the registrar. The risk lies in the order and in the way back: a DS that no longer matches any published key makes the domain unreachable for validating resolvers, while it keeps answering elsewhere. This guide gives the sequence, the verification commands with their real output, the procedure to change DNS provider without leaving an orphan DS, and what ServOrbit.com does and does not do.",[35,39,42,67,102,105,115,118,139,142,173,177,180],{"type":36,"title":37,"body":38},"h2","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.\n\nThis 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.",{"type":36,"title":40,"body":41},"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.\n\nThe 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.",{"type":43,"title":44,"steps":45},"steps","Enable DNSSEC in the right order",[46,49,52,55,58,61,64],{"title":47,"body":48},"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.",{"title":50,"body":51},"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 +short` and `dig 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.",{"title":53,"body":54},"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.",{"title":56,"body":57},"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 DNSKEY` returns the keys and their signature from each of the name servers.",{"title":59,"body":60},"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.",{"title":62,"body":63},"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.",{"title":65,"body":66},"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.",{"type":68,"title":69,"headers":70,"rows":74},"comparison","Algorithms and digests: what RFC 8624 requires",[71,72,73],"Parameter","Value","Status in RFC 8624",[75,79,83,87,91,95,98],[76,77,78],"ECDSAP256SHA256 signature","13","MUST, the usual choice",[80,81,82],"RSASHA256 signature","8","MUST",[84,85,86],"ED25519 signature","15","RECOMMENDED",[88,89,90],"ED448 and ECDSAP384SHA384 signature","16 and 14","MAY",[92,93,94],"RSASHA1 signatures and variants","5, 7 and 10","NOT RECOMMENDED",[96,97,82],"DS digest: SHA-256","2",[99,100,101],"DS digest: SHA-1 and GOST","1 and 3","MUST NOT for delegation",{"type":36,"title":103,"body":104},"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 @\u003Cparent server>`, queries the parent zone directly and must return a line of the form `\u003Ckey tag> \u003Calgorithm> \u003Cdigest type> \u003Cdigest>`, for example `2371 13 2 \u003Cdigest>` (illustrative values): the key tag must be that of the KSK published by the operator.\n\nThe 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`.",{"type":106,"title":107,"items":108},"ul","What can block you at the registrar or the registry",[109,110,111,112,113,114],"**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.",{"type":36,"title":116,"body":117},"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.\n\nRFC 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.",{"type":43,"title":119,"steps":120},"Cautious procedure for changing DNS provider",[121,124,127,130,133,136],{"title":122,"body":123},"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 @\u003Cold server> your-domain.com MX +short` then `dig @\u003Cnew server> your-domain.com MX +short`, and likewise for A and TXT.",{"title":125,"body":126},"Note the DS TTL","Query `dig DS your-domain.com @\u003Cparent server>` and note the TTL shown: it is the time during which resolvers may still believe the old DS.",{"title":128,"body":129},"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.",{"title":131,"body":132},"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.",{"title":134,"body":135},"Change the name servers","Edit the NS records at the registrar. Check the switch with `dig NS your-domain.com @\u003Cparent server>` then test resolution from a validating resolver. The guide on changing name servers details the operation in the client area.",{"title":137,"body":138},"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.",{"type":36,"title":140,"body":141},"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.\n\nTo 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.",{"type":68,"title":143,"headers":144,"rows":148},"Symptoms, causes and remedies",[145,146,147],"Symptom","Likely cause","Remedy",[149,153,157,161,165,169],[150,151,152],"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",[154,155,156],"`EDE: 9 (DNSKEY Missing)` in the dig output","No DNSKEY matches the DS","Compare the DS key tag with the published KSK",[158,159,160],"`delv` answers `resolution failed`","Broken chain of trust","Test with `dig +cd` to confirm the zone answers without validation",[162,163,164],"No `ad` flag but no error","Non-validating resolver or DS not yet published","Query another resolver, wait for the registry delay",[166,167,168],"Outage after a name server change","New operator unsigned, old DS kept","Follow the cautious procedure, starting by removing the DS",[170,171,172],"Expired signatures","Automatic signing stopped at the operator","Restart signing, compare the RRSIG dates",{"type":174,"title":175,"body":176},"tip","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`.",{"type":36,"title":178,"body":179},"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 support@servorbit.com. 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.",{"type":36,"title":181,"body":182},"The official documentation","RFC 6781, DNSSEC operational practices: https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc6781.html\n\nRFC 8624, algorithms and digests: https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8624.html\n\nRFC 7344, CDS and CDNSKEY: https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc7344.html\n\nRFC 8078, DS management by the child: https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc8078.html\n\nICANN consultation on DS automation: https:\u002F\u002Fwww.icann.org\u002Fen\u002Fannouncements\u002Fdetails\u002Ficann-seeks-input-on-security-stability-assessment-of-dnssec-ds-automation-13-10-2026-en\n\nRoot KSK rollover: https:\u002F\u002Fwww.icann.org\u002Fresources\u002Fpages\u002Fksk-rollover-en","Domains and DNS in one place","Following your domains, their name servers and your hosting from a single area makes preparing a change simpler. For a DNSSEC request, open a ticket from the client area; support depends on the extension.","Manage my domains","\u002Fdomaines",[188,204,224],{"id":189,"slug":190,"slugs":191,"title":195,"excerpt":196,"readTime":197,"views":18,"isPinned":19,"publishedAt":198,"updatedAt":199,"category":200,"categories":201,"featuredImage":30,"bgImage":31,"posterImage":203,"relatedSolution":30},493,"root-dnssec-ksk-rollover-2026-check-your-resolver",{"fr":192,"en":190,"ar":193,"es":194},"rollover-ksk-racine-dns-2026-dnssec-resolveurs","تغيير-مفتاح-الجذر-dnssec-2026-فحص-المحلل","rollover-ksk-raiz-dnssec-2026-revisar-resolver","Root DNSSEC KSK rollover: check your validating resolver","The DNS root is now signed by KSK-2024 (key tag 38696). Check the trust anchor of Unbound, BIND, Knot Resolver, systemd-resolved or dnsmasq, and fix it.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[202],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Frollover-ksk-racine-dns-2026-dnssec-resolveurs-poster.svg",{"id":205,"slug":206,"slugs":207,"title":211,"excerpt":212,"readTime":213,"views":214,"isPinned":19,"publishedAt":215,"updatedAt":216,"category":217,"categories":221,"featuredImage":30,"bgImage":31,"posterImage":223,"relatedSolution":30},449,"change-domain-nameservers",{"fr":208,"en":206,"ar":209,"es":210},"changer-serveurs-de-noms-domaine","تغيير-خوادم-الأسماء-للنطاق","cambiar-servidores-de-nombres-dominio","Change a domain's nameservers","Change the nameservers (NS) of a domain registered with ServOrbit from your client area, without taking down your website or email.",2,1,"2026-10-16T00:00:00+00:00","2026-10-16T01:57:35+00:00",{"id":197,"name":218,"slug":219,"color":220,"icon":219},"Guides","guides","bg-emerald-500\u002F10 text-emerald-400",[222],{"id":197,"name":218,"slug":219,"color":220,"icon":219},"\u002Fblog\u002Fcovers\u002Fchanger-serveurs-de-noms-domaine-poster.svg",{"id":225,"slug":226,"slugs":227,"title":231,"excerpt":232,"readTime":213,"views":214,"isPinned":19,"publishedAt":215,"updatedAt":216,"category":233,"categories":234,"featuredImage":30,"bgImage":31,"posterImage":236,"relatedSolution":30},446,"activate-managed-cloudflare-dns-domain",{"fr":228,"en":226,"ar":229,"es":230},"activer-dns-manage-cloudflare-domaine","تفعيل-dns-المدار-cloudflare-على-النطاق","activar-dns-gestionado-cloudflare-dominio","Activate managed Cloudflare DNS on a domain","Activate managed DNS (Cloudflare) for a domain from your client area: record import, nameserver delegation and checking the zone status.",{"id":197,"name":218,"slug":219,"color":220,"icon":219},[235],{"id":197,"name":218,"slug":219,"color":220,"icon":219},"\u002Fblog\u002Fcovers\u002Factiver-dns-manage-cloudflare-domaine-poster.svg",1793289220494]