October 2025 - dns-wg - mailman.ripe.net

DNS co chair
by Marco Neroni 15 Oct '25

15 Oct '25

I support Antonio as a RIPE DNS-wg co-chair KR Marco Neroni

2 1

Co-chair: I support Antonio
by Arturo BIANCHI 14 Oct '25

14 Oct '25

Hi, *I support Antonio Prado as a RIPE DNS-wg co-chair!* Looking forward to meeting you all next week in Bucharest ;-) 73, Arturo @ RINUX.

1 0

I support Antonio as a RIPE DNS-wg co-chair
by Roberto Chines 14 Oct '25

14 Oct '25

-- Roberto

1 0

Support for Antonio Prado
by Natale Tarantino 14 Oct '25

14 Oct '25

I support Antonio as a RIPE DNS-wg co-chair

1 0

Support for Antonio Prado
by Matteo Battaglia 14 Oct '25

14 Oct '25

I support Antonio as a RIPE DNS-wg co-chair

1 0

support for Antonio Prado
by Salvatore Patti 14 Oct '25

14 Oct '25

+1 for Antonio

1 0

support for Antonio Prado
by Victor Bolaños Guerra 14 Oct '25

14 Oct '25

+1 for Antonio -- Víctor Bolaños Training Manager & Consultant +34 911 88 03 66 +34 605 75 90 75 <https://www.linkedin.com/in/victorbguerra/> <https://telegram.me/vitokosk8> fibercli.com lo0.es <https://www.lo0.es/> Este mensaje va dirigido, de manera exclusiva, a su destinatario y puede contener información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por Ley. En caso de haber recibido este mensaje por error, le rogamos que de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. En aras del cumplimiento del Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, puede ejercer los derechos de acceso, rectificación, cancelación, limitación, oposición y portabilidad de manera gratuita mediante correo electrónico a: lopd(a)fibercli.com

1 0

support for Antonio Prado
by Sandro Facondini 14 Oct '25

14 Oct '25

I support Antonio Prado as a RIPE DNS-wg co-chair, thank you! -- Sandro Facondini CTO TeleneT RSM AS196874

1 0

Re: Co-chair selection for the RIPE DNS working group
by Giuseppe Abate | Fiber Telecom 14 Oct '25

14 Oct '25

+1 for Antonio Regards *Giuseppe Abate* NOC Team Leader Phone +39 02 8994 1111 -- *FIBER TELECOM S.p.A.* · Via Caldera, 21 - 20153 Milano Italy · www.fibertelecom.com <https://www.fibertelecom.com/> · Phone +39 02 8994 1111 <https://www.youtube.com/channel/UCacxeJwRrZycr6atxCZqopw>PRIVACY <https://www.fibertelecom.com/en/privacy-policy.php> - GDPR - EU Regulation 2016/679

1 0

Should parents look for CDNSKEY or CDS, or both?
by Peter Thomassen 14 Oct '25

14 Oct '25

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.

1 0