Automating DNSSEC Delegation Trust Maintenance
updated by
Extracted elements (28)
A polling trigger was chosen for simplicity; other triggers (web button, REST interface, DNS NOTIFY) are acknowledged as valid but left for other documents to specify, keeping this document focused.
CDS/CDNSKEY maintenance of delegation keys is kept separate from CPSYNC (NS/glue maintenance) because the problems are fundamentally different and a combined solution would be overly complex.
The solution is intentionally DS vs. DNSKEY agnostic: some Parents want the Child to express keys as DS records, others prefer to receive DNSKEY and calculate DS themselves. Supporting both avoids forcing a choice where no consensus exists.
Using the DNS itself as the communication channel for DS updates was chosen over push-based mechanisms (e.g., DNS UPDATE) because finding the Parental Agent/server to push to proved unresolvable in practice — that approach failed to reach consensus.
Using the SEP bit in DNSKEY to drive DS selection was rejected because it gives the Child no control over DS digest algorithms and is incompatible with Double-DS rollover, which requires DS records for keys not yet in the DNSKEY RRset.
The Parental Agent that consumes CDS/CDNSKEY records must understand the specific signing rules in Section 4.1 and therefore may not be able to use a standard DNSSEC validator without modification.
This protocol only automates subsequent DS updates after the initial key has been established; it does not support initial enrollment or complete removal of all keys, so out-of-band communication mechanisms must always exist in parallel.
When a Parent fetches CDNSKEY and calculates DS itself, the resulting DS records may differ from any CDS the Child published, with differences expected only in the set of digest algorithms used.
CDS/CDNSKEY records MUST be located at the Child zone apex, MUST be signed with a key represented in both the current DNSKEY and DS RRsets (except for initial enrollment), and MUST NOT break the current delegation if applied to the DS RRset.
If any of the acceptance conditions (location, signer, continuity) fail, the CDS or CDNSKEY resource record MUST be ignored, and this error SHOULD be logged.
If the CDS/CDNSKEY RRsets do not exist, the Parental Agent MUST take no action — specifically it MUST NOT delete or alter the existing DS RRset.
If the Child publishes either CDS or CDNSKEY, it SHOULD publish both. If the Child publishes both, the two RRsets MUST match in content. A Child MAY choose to publish only one type if it knows which the Parent consumes.
Once the Parental Agent has obtained a valid CDS/CDNSKEY RRset, it MUST check the publication rules from Section 4.1, and in particular MUST check the Continuity rule to avoid invalidating the Child zone.
The CDS/CDNSKEY technique SHOULD NOT be used for initial enrollment of keys since there is no way to ensure that the initial key is the correct one. If it is used for enrollment, strict hold-down times, challenge data, or similar rules MUST be applied.
The Parent MUST choose either CDNSKEY or CDS as its default updating mechanism. The Parent MAY accept both but MUST NOT expect there to be both.
The Parental Agent MUST ensure that previous versions of the CDS/CDNSKEY RRset do not overwrite more recent versions. This MAY be accomplished by checking that the RRSIG signature inception is later and/or that the Child SOA serial is greater.
The Parental Agent SHOULD use a DNSSEC validator to obtain a validated CDS/CDNSKEY RRset from the Child zone. An exception (NOT RECOMMENDED) is if the Parent performs additional validation to confirm the key is correct.
This mechanism SHOULD NOT be used to bypass intermediaries (e.g., Registrars) that might cache delegation information, as doing so may result in inconsistent views of the DNSSEC key material between Registry and Registrar.
Use of CDS/CDNSKEY is OPTIONAL. The CDS/CDNSKEY RRset expresses what the Child would like the DS RRset to look like after the change; it is a replace operation. If neither CDS nor CDNSKEY RRset is present in the Child, this signals that no change should be made to the current DS set.
All information handled or transmitted by this protocol is public information published in the DNS; there are no privacy concerns introduced by the CDS/CDNSKEY mechanism.
The CDNSKEY (Child DNSKEY) resource record, assigned RR type 60, has wire and presentation format identical to the DNSKEY record. It is published in the Child zone to signal desired DS content to the Parent by conveying the raw key material. No special processing is performed by authoritative servers or resolvers.
The CDS (Child DS) resource record, assigned RR type 59, has wire and presentation format identical to the DS record (RFC 4034). It is published in the Child zone to convey to the Parent the desired contents of the zone's DS RRset. No special processing is performed by authoritative servers or resolvers.
IANA assigned RR type code 59 for the CDS resource record (reference: this document) and RR type code 60 for the CDNSKEY resource record (meaning: 'DNSKEY(s) the Child wants reflected in DS'). Both were allocated via Expert Review.
A compromise of the signing system for a Child zone could allow an attacker to publish malicious CDS/CDNSKEY records, causing the Parent to update DS records in the attacker's favor and extending the effective duration of the attack. A hold-down delay (as in RFC 5011) can limit this window.
Deploying CDS/CDNSKEY removes the need for third-party DNS operators to hold Registrar login credentials in order to update DNSSEC information, which improves security by reducing credential exposure.
DNS cache coherence must be respected: old information must be allowed to expire before deleting DS or DNSKEY records, and new records must propagate before use, to avoid transient validation failures.
If multiple DNS servers serving the Child zone are not fully synchronized, the Parental Agent may observe inconsistent CDS RRsets across queries, potentially causing it to reverse a prior correct DS update and break the delegation.
KSK rollover using CDS (Double-DS method): (1) Child publishes CDS with keys AB; (2) Parent updates DS to AB after detecting change; (3) Child switches active KSK from A to B; (4) Child removes key A from CDS (CDS=B); (5) Parent removes DS for A (DS=B); (6) optionally Child removes CDS entirely. Each transition requires waiting for TTL expiry of the prior RRset.