Managing DS Records from the Parent via CDS/CDNSKEY
updated by
- rfc-9615 — Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator
updates
- rfc-7344 — Automating DNSSEC Delegation Trust Maintenance
Extracted elements (20)
Algorithm 0 was chosen for the delete signal because no DNSSEC validator can treat it as a valid signature algorithm; if a validator sees a DNSKEY or DS with algorithm 0, it treats it as unknown, causing the zone to be treated as unsigned.
Multiple acceptance policies are defined (authenticated channel, extra checks, delay-based, challenge-based, from inception) because there is a large variety of legal frameworks surrounding parent domains, making a single universal policy impossible.
RFC 7344 lacked two options needed for full automation: a method for initial trust establishment and a 'delete' signal for removing DNSSEC. This document adds both, elevating RFC 7344 to Standards Track.
The inability to disable DNSSEC via in-band signaling was cited as a reason some operators cannot deploy DNSSEC, as it creates operational risk with no exit path. This document introduces a delete signal to address that concern.
This document elevates RFC 7344 from Informational to Standards Track based on deployment experience showing CDS and CDNSKEY are useful for DNSSEC deployment. All normative content of RFC 7344 is preserved.
When accepting CDS via authenticated channel, parents may limit the DS record type based on local policy. In the CDNSKEY case, the parent retrieves the CDNSKEY RRset and calculates the DS record(s) itself.
Once the parent has verified the delete CDS/CDNSKEY RRset and it has passed other acceptance tests, the parent MUST remove the DS RRset.
Parents SHOULD NOT refuse CDS/CDNSKEY updates that do not yet have a matching DNSKEY in the child zone, allowing the child to pre-publish a spare or potentially offline DNSKEY.
The contents of the delete CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields 'CDS 0 0 0 0' or 'CDNSKEY 0 3 0 0'; no other notation is permitted.
CDS (Child DS) and CDNSKEY (Child DNSKEY) records signal three operations to the parent: (1) enable DNSSEC by publishing an initial DS RRset, (2) roll over the KSK, and (3) turn off DNSSEC by deleting all DS records.
DNS Security Algorithm Number 0 is defined in the context of CDS and CDNSKEY records to signal deletion of the entire DS RRset at the parent. The value 0 remains reserved for DS and DNSKEY records themselves.
Publishing a CDS or CDNSKEY RRset signals to the parent that the child desires the corresponding DS records to be synchronized. The CDS RRset is an instruction to modify the DS RRset if the CDS and DS RRsets differ.
The 'Accept after Delay' policy has the parent monitor the CDS RRset at child nameservers over a period of time, preferably from different network vantage points, before accepting it as a valid signal.
The 'Accept from Inception' policy allows a parent adding a new child domain to immediately publish a DS RRset alongside the new NS RRset using the child's CDS/CDNSKEY, ensuring the domain is never active in an insecure state.
The 'Accept with Challenge' policy requires the requester to insert a specific record into the child zone to prove operational control. The parent verifies the challenge is published by all child nameservers from diverse network locations.
IANA assigned entry number 0 in the 'DNS Security Algorithm Numbers' registry with description 'Delete DS', mnemonic 'DELETE', Zone Signing 'N', Trans. Sec. 'N', referencing RFC 4034, RFC 4398, and RFC 8078.
A parent SHOULD ensure that when allowing a child to become securely delegated, the CDS/CDNSKEY RRset used to bootstrap security is visible from a geographically and topologically diverse view, and that the zone validates correctly after DS publication.
Parental zones should pick the most secure acceptance method possible within their legal and technical scenario, while still enabling a fully automated method for non-direct parties such as third-party DNS hosters.
Turning off DNSSEC reduces domain security and should only be done as a last resort to prevent validation errors from mismatched DS and DNSKEY records. Re-establishing trust in delegation can be hard and takes time.
The delete CDS record is encoded as 'CDS 0 0 0 0' and the delete CDNSKEY record as 'CDNSKEY 0 3 0 0', where the keying material payload is a single 0. The value 3 in the CDNSKEY second field is mandated by RFC 4034 Section 2.1.2.