--- Begin Message ---
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.
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
