Dear DNS aficionados, At DNS OARC last week, a discussion emerged about a recommendation in IETF draft-ietf-dnsop-ds-automation, namely: Section 6.1: 2. Parents, independently of their preference for CDS or CDNSKEY, SHOULD require publication of both RRsets, and SHOULD NOT proceed with updating the DS RRset if one is found missing or inconsistent with the other. While this at first glance indeed may seem like a not-so-good idea, there are some arguments why the alternative may be an even worse idea. An analysis of the problem is given in Section 6.2, which for convenience I'm pasting below. It would be extremely helpful to learn what's the view of DNSOP participants on this matter, so you are invited :-) Several notes: a) The draft is only for new deployments of DS automation; it is not trying to create work for existing ones. b) The previous recommendation tells children to publish both; this one is about the parent-side enforcement. c) A misconception (to be clarified in the draft): the above does not prevent the parent from choosing a digest type that's not in CDS. It requires only that both RRsets exist and refer to the same keys, not that the parent uses the exact digest types for the DS RRset. Thanks! Peter Sheng & Thomassen Expires 9 March 2026 [Page 14] Internet-Draft DS Automation September 2025 ... 6.2. Analysis DS records can be generated from information provided either in DS format (CDS) or in DNSKEY format (CDNSKEY). While the format of CDS records is identical to that of DS records (so the record data be taken verbatim), generation of a DS record from CDNSKEY information involves computing a hash. Whether a Parent processes CDS or CDNSKEY records depends on their preference: * Conveying (and storing) CDNSKEY information allows the Parent to control the choice of hash algorithms. The Parent may then unilaterally regenerate DS records with a different choice of hash algorithm(s) whenever deemed appropriate. * Conveying CDS information allows the Child DNS operator to control the hash digest type used in DS records, enabling the Child DNS operator to deploy (for example) experimental hash digests and removing the need for registry-side changes when new digest types become available. The need to make a choice in the face of this dichotomy is not specific to DS automation: even when DNSSEC parameters are relayed to the Parent through conventional channels, the Parent has to make some choice about which format(s) to accept. Some registries have chosen to prefer DNSKEY-style input which seemingly comes with greater influence on the delegation's security properties (in particular, the DS hash digest type). It is noted that regardless of the choice of input format, the Parent cannot prevent the Child from following insecure cryptographic practices (such as insecure key storage, or using a key with insufficient entropy). Besides, as the DS format contains a field indicating the hash digest type, objectionable ones (such as those outlawed by [DS-IANA]) can still be rejected even when ingesting CDS records, by inspecting that field. The fact that more than one input type needs to be considered burdens both Child DNS operators and Parents with the need to consider how to handle this dichotomy. Until this is addressed in an industry-wide manner and one of these mechanisms is deprecated in favor of the other, both Child DNS operators and Parents implementing automated DS maintenance should act as to maximize interoperability: * As there exists no protocol for Child DNS Operators to discover a Parent's input format preference, it seems best to publish both CDNSKEY as well as CDS records, in line with [RFC7344], Section 5. The choice of hash digest type should follow current best practice [DS-IANA]. * Parents, independently of their input format preference, are advised to require publication of both CDS and CDNSKEY records, and to enforce consistency between them, as determined by matching CDS and CDNSKEY records using hash digest algorithms whose support is mandatory [DS-IANA]. (Consistency of CDS records with optional or unsupported hash digest types is not required.) Publishing the same information in two different formats is not ideal. Still, it is much less complex and costly than burdening the Child DNS operator with discovering each Parent's policy; also, it is very easily automated. Operators should ensure that published RRsets are consistent with each other. By rejecting the DS update if either RRset is found missing or inconsistent with the other, Child DNS operators are held responsible when publishing contradictory information. At the same time, Parents can retain whatever benefit their policy choice carries for them, while facilitating a later revision of that choice. This approach also simplifies possible future deprecation of one of the two formats, as no coordination or implementation changes would be needed on the child side.