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" > > -------------------------------------- > You may review the report below and at: > https://errata.rfc-editor.org/eid9180/ > > -------------------------------------- > 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://www.rfc-editor.org/info/rfc9250>. > > 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
