Should parents look for CDNSKEY or CDS, or both?

[Peter Thomassen]

Dear friends,

At DNS OARC last week, a discussion emerged about a recommendation in 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.