Redirecting to DNSOP@ietf.org<mailto:DNSOP@ietf.org>, which is a more suitable place than the concluded dnsext WG.
-éric From: RFC Errata System <rfc-edi...@rfc-editor.org> Date: Thursday, 27 March 2025 at 02:25 To: j...@bondis.org <j...@bondis.org>, explo...@flame.org <explo...@flame.org>, vi...@isc.org <vi...@isc.org>, ek.i...@gmail.com <ek.i...@gmail.com>, Eric Vyncke (evyncke) <evyn...@cisco.com>, o...@ogud.com <o...@ogud.com>, a...@anvilwalrusden.com <a...@anvilwalrusden.com> Cc: edmo...@mycre.ws <edmo...@mycre.ws>, dns...@ietf.org <dns...@ietf.org>, rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> Subject: [Technical Errata Reported] RFC6891 (8348) The following errata report has been submitted for RFC6891, "Extension Mechanisms for DNS (EDNS(0))". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8348 -------------------------------------- Type: Technical Reported by: Robert Edmonds <edmo...@mycre.ws> Section: 6.1.2 Original Text ------------- The fixed part of an OPT RR is structured as follows: +------------+--------------+------------------------------+ | Field Name | Field Type | Description | +------------+--------------+------------------------------+ | NAME | domain name | MUST be 0 (root domain) | | TYPE | u_int16_t | OPT (41) | | CLASS | u_int16_t | requestor's UDP payload size | | TTL | u_int32_t | extended RCODE and flags | | RDLEN | u_int16_t | length of all RDATA | | RDATA | octet stream | {attribute,value} pairs | +------------+--------------+------------------------------+ Corrected Text -------------- The fixed part of an OPT RR is structured as follows: +------------+--------------+------------------------------+ | Field Name | Field Type | Description | +------------+--------------+------------------------------+ | NAME | domain name | MUST be 0 (root domain) | | TYPE | u_int16_t | OPT (41) | | CLASS | u_int16_t | sender's UDP payload size | | TTL | u_int32_t | extended RCODE and flags | | RDLEN | u_int16_t | length of all RDATA | | RDATA | octet stream | {attribute,value} pairs | +------------+--------------+------------------------------+ Notes ----- This restores the definition of EDNS0's OPT CLASS field as "sender's UDP payload size" as it appeared in RFC 2671 rather than "requestor's UDP payload size" which appeared in RFC 6891 (specifically it appears to have been introduced in draft-ietf-dnsext-rfc2671bis-edns0-02). The requestor is not the same as the sender. The requestor is the protocol endpoint that sends the DNS query message and receives the DNS response message, while the responder is the protocol endpoint that receives the DNS query message and sends the DNS response message. The requestor is the sender when it sends its DNS query message to the responder, and the responder is the sender when it sends its DNS response message to the requestor. 6891 specifically defines requestor/responder as: "Requestor" refers to the side that sends a request. "Responder" refers to an authoritative, recursive resolver or other DNS component that responds to questions. 6891's definition of the OPT CLASS field as the "requestor's UDP payload size" thus literally means that the responder should copy the requestor's UDP payload size into the OPT CLASS field in the response message that the responder sends. There would then be no place in the packet for the responder to place the responder's UDP payload size, and besides, the requestor doesn't need this information since it already knows its own payload size. This is not consistent with the EDNS0 protocol as a whole, which involves the protocol endpoints (requestor and responder) learning each other's maximum UDP payload sizes, for instance 6891 section 6.2.4: The responder's maximum payload size can change over time but can reasonably be expected to remain constant between two closely spaced sequential transactions, for example, an arbitrary QUERY used as a probe to discover a responder's maximum UDP payload size, followed immediately by an UPDATE that takes advantage of this size. In practice, I believe modern EDNS0 responder implementations follow the earlier definition from 2671 and the "requestor's UDP payload size" definition in 6891 is a drafting mistake. Thanks! Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) 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. -------------------------------------- RFC6891 (draft-ietf-dnsext-rfc2671bis-edns0-10) -------------------------------------- Title : Extension Mechanisms for DNS (EDNS(0)) Publication Date : April 2013 Author(s) : J. Damas, M. Graff, P. Vixie Category : INTERNET STANDARD Source : DNS Extensions Stream : IETF Verifying Party : IESG
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
