Hi all, Thank you Ondrej for sharing your thoughts.
I don't think flagging the erratum as currently reported as editorial is accurate, especially that this suggests to add a new normative reference. Now looking into the proposed changes and current text: CURRENT: As catalog zones are transmitted using DNS zone transfers, it is RECOMMENDED that catalog zone transfers be protected from unexpected modifications by way of authentication, e.g., by using a Transaction Signature (TSIG) [RFC8945] or Strict or Mutual TLS authentication with DNS zone transfer over TLS or QUIC [RFC9103]. These are examples, if 9250 have to be cited, it would be informative. Agree with Ondrej there is no error here. CURRENT: Catalog zones reveal the zones served by their consumers, including their properties. To prevent unintentional exposure of catalog zone contents, it is RECOMMENDED to limit the systems able to query them and to conduct catalog zone transfers confidentially [RFC9103]. 9103 is one way to achieve this. In the meantime, RFC9250 says that it mimics 9103 for these matters. Having 9103 alone might be sufficient for the purpose. So, if we have to make a change, the following minimal one (but still technical) would be more accurate IMO: NEW: Catalog zones reveal the zones served by their consumers, including their properties. To prevent unintentional exposure of catalog zone contents, it is RECOMMENDED to limit the systems able to query them and to conduct catalog zone transfers confidentially (e.g., [RFC9103]). The erratum can be tweaked as needed. Cheers, Med > -----Message d'origine----- > De : Ondřej Surý <[email protected]> > Envoyé : jeudi 17 septembre 2026 17:28 > À : [email protected] > Cc : [email protected]; [email protected]; [email protected]; > BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: [Technical Errata Reported] RFC9432 (9180) > > > This isn't a technical errata really: > > > Technical errata are expected to be things that would likely > cause significant misunderstandings of the technical specification > and might result in faulty implementations if they are not > corrected. > > This either needs to be rejected, or can be marked as Editorial > with "Hold for Document Update" state. > > Ondrej > -- > Ondřej Surý (He/Him) > [email protected] > > A gentle nudge is always appreciated if I take a little longer to > reply. > > > On 17. 9. 2026, at 17:12, [email protected] wrote: > > > > The following errata report has been submitted for RFC9432, "DNS > > Catalog Zones" > > > > Type: Technical > > Reported by: Antun Jurkovikj <[email protected]> > > > > Section 7 and 9.1 says: > > > > Original Text > > ------------- > > As catalog zones are transmitted using DNS zone transfers, it is > > RECOMMENDED that catalog zone transfers be protected from > unexpected > > modifications by way of authentication, e.g., by using a > Transaction > > Signature (TSIG) [RFC8945] or Strict or Mutual TLS > authentication with > > DNS zone transfer over TLS or QUIC [RFC9103]. > > > > Use of DNS UPDATE [RFC2136] to modify the content of catalog > zones > > SHOULD similarly be authenticated. > > > > Zone transfers of member zones SHOULD similarly be > authenticated. > > TSIG shared secrets used for member zones SHOULD NOT be > mentioned in > > the catalog zone data. However, key identifiers may be shared > within > > catalog zones. > > > > Catalog zones reveal the zones served by their consumers, > including > > their properties. To prevent unintentional exposure of catalog > zone > > contents, it is RECOMMENDED to limit the systems able to query > them > > and to conduct catalog zone transfers confidentially [RFC9103]. > > > > Corrected Text > > -------------- > > As catalog zones are transmitted using DNS zone transfers, it is > > RECOMMENDED that catalog zone transfers be protected from > unexpected > > modifications by way of authentication, e.g., by using a > Transaction > > Signature (TSIG) [RFC8945] or Strict or Mutual TLS > authentication with > > DNS zone transfer over TLS or QUIC [RFC9103] [RFC9250]. > > > > Use of DNS UPDATE [RFC2136] to modify the content of catalog > zones > > SHOULD similarly be authenticated. > > > > Zone transfers of member zones SHOULD similarly be > authenticated. > > TSIG shared secrets used for member zones SHOULD NOT be > mentioned in > > the catalog zone data. However, key identifiers may be shared > within > > catalog zones. > > > > Catalog zones reveal the zones served by their consumers, > including > > their properties. To prevent unintentional exposure of catalog > zone > > contents, it is RECOMMENDED to limit the systems able to query > them > > and to conduct catalog zone transfers confidentially [RFC9103] > > [RFC9250]. > > > > Notes > > ----- > > RFC 9103 specifies DNS zone transfer over TLS. RFC 9250 > specifies DNS > > over QUIC, including AXFR and IXFR in Section 5.7. Its Section > > 5.1 retains RFC 9103's authentication requirements for zone > transfer. > > > > Section 7 already includes QUIC. Adding RFC 9250 supplies its > defining > > reference while retaining RFC 9103. This does not change the > existing > > authentication or confidentiality recommendations. > > > > Add the following entry to Section 9.1 (Normative References): > > > > [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over > > Dedicated QUIC Connections", RFC 9250, > > DOI 10.17487/RFC9250, May 2022, > > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Finfo%2Frfc9250&data=05%7C02%7Cmohamed.boucadair%40ora > nge.com%7C88b0bc13792d4612cd1a08df14d04e6e%7C90c7a20af34b40bfbc48b > 9253b6f5d20%7C0%7C0%7C639252557039133180%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=THCJ0BHlJV%2BXcxpV%2B > bYt60QOhDLugUKfdC6fFf2Bbd0%3D&reserved=0>. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". Please use > "Reply All" > > to discuss whether it should be verified or rejected. When a > decision > > is reached, the verifying party will log in to change the status > and > > edit the report, if necessary. > > > > -------------------------------------- > > RFC9432 (draft-ietf-dnsop-dns-catalog-zones) > > -------------------------------------- > > Title : DNS Catalog Zones > > Publication Date : July 2023 > > Author(s) : P. van Dijk, L. Peltan, O. Surý, W. > Toorop, C.R. Monshouwer, P. Thomassen, A. Sargsyan > > Category : Proposed Standard > > Source : dnsop (ops) > > Stream : IETF > > Verifying Party : IESG ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
