[DNSOP] Re: [Technical Errata Reported] RFC6891 (8348)

["Eric Vyncke (evyncke)" <[e-mail]>]

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) <[e-mail]>
Date: Tuesday, 1 April 2025 at 13:16
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Mohamed Boucadair <[e-mail]>, Mahesh Jethanandani <[e-mail]>
Subject: [DNSOP] Re: [Technical Errata Reported] RFC6891 (8348)
Redirecting to [e-mail]<mailto:[e-mail]>, which is a more suitable place than the concluded dnsext WG.

-éric

From: RFC Errata System <[e-mail]>
Date: Thursday, 27 March 2025 at 02:25
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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 <[e-mail]>

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