DS records and delegation at the registrar, the secure way

#What goes wrong

DNS is a tree. The com zone delegates example.com to your name servers with NS records. With DNSSEC, the parent also publishes a DS record: a hash of your key signing key (KSK). A validating resolver trusts your keys only because the parent's signed DS says so.

You control your zone. You do not control the parent. For most domains, the only way to change the DS is through your registrar, which passes it to the registry. That creates four common failures:

• No DS at all. The zone is signed, but resolvers treat it as unsigned.
• A wrong DS: a typo, an old key, the DNSKEY pasted where a DS was expected. Every validating resolver returns SERVFAIL for every name.
• A DS left behind after DNSSEC is turned off, or after moving to a DNS provider with different keys. Same result: the domain is dark.
• NS records at the parent that do not match the zone. Some resolvers ask servers that no longer serve the zone, or that serve an old copy.

#What the docs say

Once the parent has verified the CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset.

Source: RFC 8078, Section 4

Remember to update the DS record in the parent zone to include a reference to the new key.

Source: Knot DNS 3.5 docs, Manual key management

This is how to "disconnect" a signed zone from a DNSSEC-aware parent zone.

Source: Knot DNS 3.5 docs, DNSSEC delete algorithm

RFC 8624, Section 3.3 lists SHA-1 (digest type 1) as "MUST NOT" for DS records and SHA-256 (type 2) as "MUST". Signer docs stop at "update the DS in the parent". They do not cover the registrar side: forms that accept a DNSKEY instead of a DS, forms that add rather than replace, and registrars that support CDS scanning (RFC 7344, RFC 8078) versus those that do not.

#The secure configuration

Get the DS from the signer and copy it as text, never by retyping:

keymgr example.com. ds <ksk-tag>
# example.com. DS <tag> 13 2 <sha-256 hex>   <- submit this one
# example.com. DS <tag> 13 4 <sha-384 hex>   <- optional; never use type 1 (SHA-1)

Most registrar forms ask for four fields. Map them from the DS line:

example.com. DS 32926 13 2 fe1fe401e0399835ce27739a32effbf52fbf67e0f8763e0426df9583cc4f0dd8
                |     |  |  '-- Digest
                |     |  '----- Digest type: 2 (SHA-256)
                |     '-------- Algorithm: 13 (ECDSA P-256 SHA-256)
                '-------------- Key tag

If the form asks for a DNSKEY instead, give the KSK (flags 257) from keymgr example.com. dnskey <ksk-tag>; the registry computes the DS.

Publish CDS and CDNSKEY so registries that scan (RFC 8078) can pick up the DS themselves, and so you can compare:

policy:
  - id: secure
    cds-cdnskey-publish: always      # or rollover: only during KSK changes

After every change, check the parent directly. Ask one of its servers, not a resolver:

kdig +short NS com.                               # find the parent's servers
kdig @a.gtld-servers.net example.com DS +norecurse +short
kdig @a.gtld-servers.net example.com NS +norecurse   # referral: authority section
kdig @ns1.example.com example.com NS +norecurse +short
# The two NS sets must be the same names. Then validate from outside:
delv @198.51.100.53 www.example.com A              # a validating resolver you trust

Leaving DNSSEC, in this order:

policy:
  - id: secure
    cds-cdnskey-publish: delete-dnssec   # publishes CDS "0 0 0 00" and CDNSKEY "0 3 0 AA=="

1. Publish the delete CDS/CDNSKEY (Knot: cds-cdnskey-publish: delete-dnssec).
2. Remove the DS at the registrar (or let a scanning registry do it).
3. Confirm the parent no longer serves a DS.
4. Wait at least the old DS TTL.
5. Turn signing off.

Moving to another DNS provider: add the new provider's DS next to yours (or share keys), switch the NS records, and remove your DS only after the old NS TTL has passed. Never switch NS to a provider whose keys the DS does not cover.

#Prove it

The test (secure-tests/ds-records-delegation-registrar/run.sh) serves a stand-in com. zone (the registry) and example.com on one Knot 3.5.4 instance. TSIG-signed updates to com. play the registrar. delv validates from a com. trust anchor.

State 1, unsigned zone, no DS:

$ kdig @127.0.0.1 example.com DS +norecurse +short   # what the parent publishes

$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
; unsigned answer

State 2, the zone is signed but the parent has no DS. To validators it is still unsigned:

$ kdig @127.0.0.1 example.com DS +norecurse +short   # what the parent publishes

$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
;; validating www.example.com/A: no valid signature found
; unsigned answer

What goes to the registrar, and the matching CDS the zone publishes:

keymgr example.com ds 32926
kdig @127.0.0.1 example.com CDS +norecurse +short

example.com. DS 32926 13 2 fe1fe401e0399835ce27739a32effbf52fbf67e0f8763e0426df9583cc4f0dd8
example.com. DS 32926 13 4 9f6661828d001ec481916d1063f164877573a6f0fa9962e33fdb932c84ec6b5c48ea78c93b92077a2644331d4ab73023

32926 13 2 FE1FE401E0399835CE27739A32EFFBF52FBF67E0F8763E0426DF9583CC4F0DD8

State 3, a DS with the last character wrong, as from a bad copy:

$ kdig @127.0.0.1 example.com DS +norecurse +short   # what the parent publishes
32926 13 2 FE1FE401E0399835CE27739A32EFFBF52FBF67E0F8763E0426DF9583CC4F0DD0

$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
;; validating example.com/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving 'example.com/DNSKEY/IN': 127.0.0.1#53
;; broken trust chain resolving 'www.example.com/A/IN': 127.0.0.1#53

State 4, the correct DS:

$ kdig @127.0.0.1 example.com DS +norecurse +short   # what the parent publishes
32926 13 2 FE1FE401E0399835CE27739A32EFFBF52FBF67E0F8763E0426DF9583CC4F0DD8

$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
; fully validated

State 5, leaving DNSSEC in the right order. The zone publishes the delete signal, the DS is removed, and the zone is insecure, not bogus, both before and after signing is turned off:

$ kdig @127.0.0.1 example.com CDS +norecurse +short; kdig @127.0.0.1 example.com CDNSKEY +norecurse +short
0 0 0 00
0 3 0 AA==

(the registrar or registry removes the DS)
$ kdig @127.0.0.1 example.com DS +norecurse +short   # what the parent publishes

$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
;; validating www.example.com/A: no valid signature found
; unsigned answer

(after the old DS TTL has passed, signing can be turned off)
$ delv @127.0.0.1 -a anchor.conf +root=com www.example.com A
;; validating www.example.com/A: no valid signature found
; unsigned answer

#Mistakes people make

#Retyping the digest

A single wrong character makes the domain bogus, as state 3 shows. Copy the DS as text from the signer and compare it with the published CDS before you press save.

#Turning DNSSEC off before removing the DS

If the zone stops signing while the parent still has a DS, the domain is bogus until the DS is gone and its TTL has passed. Remove the DS first, then unsign. The same applies when a hosting provider "turns DNSSEC off" for you.

#Moving DNS providers with the old DS in place

The new provider signs with its own keys. The parent still points to the old provider's KSK. Plan the move: new DS first, then NS, then remove the old DS.

#Picking SHA-1 because the form lists it first

Digest type 1 is SHA-1, which RFC 8624 says MUST NOT be used for new DS records. Use type 2.

#Parent and child NS sets that disagree

The registrar's NS list and the NS records in your zone drift apart after server changes. Resolvers then ask servers that are gone or stale. Compare both lists after every change of name servers.

#Assuming the registrar supports CDS scanning

Some registries scan CDS and update the DS on their own; most registrars do not. Find out which case you are in before the first KSK rollover.

#Checklist

• Submit a digest type 2 (SHA-256) DS, copied from keymgr <zone> ds.
• Never submit a digest type 1 (SHA-1) DS.
• Compare the DS at the parent with the CDS your zone publishes.
• Query the parent's servers directly with +norecurse after every change.
• Validate with delv through a resolver outside your network.
• Keep the parent's NS names equal to the zone apex NS names.
• Remove the DS before turning signing off, and wait the old DS TTL.
• When changing DNS providers, publish the new DS before changing NS.
• Know whether your registrar or registry scans CDS (RFC 8078).
• Protect the registrar account with a hardware key and a change lock.