The errata is correct based on my reading of section 6.2.4. This is unfortunate because I disagree with section 6.2.4, but apparently I am in the rough.
On Fri, Jun 27, 2025, at 10:35 AM, Eric Vyncke (evyncke) wrote: > Any taker on this errata ? It is about the subtle difference between “sender” > and “requestor” in the ENDS(0) context > > Regards > > -éric > > *From: *Eric Vyncke (evyncke) <[email protected]> > *Date: *Tuesday, 1 April 2025 at 13:16 > *To: *[email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, [email protected] > <[email protected]> > *Cc: *[email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, Mohamed Boucadair > <[email protected]>, Mahesh Jethanandani <[email protected]> > *Subject: *[DNSOP] Re: [Technical Errata Reported] RFC6891 (8348) > Redirecting to [email protected], which is a more suitable place than the > concluded dnsext WG. > > -éric > > *From: *RFC Errata System <[email protected]> > *Date: *Thursday, 27 March 2025 at 02:25 > *To: *[email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, [email protected] > <[email protected]>, Eric Vyncke (evyncke) <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]> > *Cc: *[email protected] <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]> > *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 <[email protected]> > > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
