[DNSOP] Re: [Technical Errata Reported] RFC6891 (8348 )
"Eric Vyncke \(evyncke\)" <[email protected]> Tue, 1 Apr 2025 11:16:58 +0000
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.dnsext |
|---|---|
| Message-ID | <PH0PR11MB4966576F636A37C85A8AD845A9AC2@PH0PR11MB4966.namprd11.prod.outlook.com> |
--===============7643922443604117641== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_PH0PR11MB4966576F636A37C85A8AD845A9AC2PH0PR11MB4966namp_" --_000_PH0PR11MB4966576F636A37C85A8AD845A9AC2PH0PR11MB4966namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Redirecting to [email protected]<mailto:[email protected]>, which is a more suita= ble place than the concluded dnsext WG. -=E9ric From: RFC Errata System <[email protected]> Date: Thursday, 27 March 2025 at 02:25 To: [email protected] <[email protected]>, [email protected] <[email protected]= rg>, [email protected] <[email protected]>, [email protected] <[email protected]>, = Eric Vyncke (evyncke) <[email protected]>, [email protected] <[email protected]>, a= [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 pa= yload 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 int= roduced 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 mes= sage, while the responder is the protocol endpoint that receives the DNS qu= ery 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 si= ze" 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 res= ponder 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 pr= otocol endpoints (requestor and responder) learning each other's maximum UD= P 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 ea= rlier definition from 2671 and the "requestor's UDP payload size" definitio= n 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 --_000_PH0PR11MB4966576F636A37C85A8AD845A9AC2PH0PR11MB4966namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"en-BE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Redirecting to <a href=3D"mailto:[email protected]">[email protected]</a>, which is a more suita= ble place than the concluded dnsext WG.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">-=E9ric<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <b><span style=3D"color:black">From: </span></b><span style=3D"color:black"= >RFC Errata System <[email protected]><br> <b>Date: </b>Thursday, 27 March 2025 at 02:25<br> <b>To: </b>[email protected] <[email protected]>, [email protected] <= [email protected]>, [email protected] <[email protected]>, ek.ietf@gmail.= com <[email protected]>, Eric Vyncke (evyncke) <[email protected]&= gt;, [email protected] <[email protected]>, [email protected] <ajs@an= vilwalrusden.com><br> <b>Cc: </b>[email protected] <[email protected]>, [email protected] <d= [email protected]>, [email protected] <[email protected]= ><br> <b>Subject: </b>[Technical Errata Reported] RFC6891 (8348)<o:p></o:p></span= ></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span style=3D"font-siz= e:11.0pt">The following errata report has been submitted for RFC6891,<br> "Extension Mechanisms for DNS (EDNS(0))".<br> <br> --------------------------------------<br> You may review the report below and at:<br> <a href=3D"https://www.rfc-editor.org/errata/eid8348">https://www.rfc-edito= r.org/errata/eid8348</a><br> <br> --------------------------------------<br> Type: Technical<br> Reported by: Robert Edmonds <[email protected]><br> <br> Section: 6.1.2<br> <br> Original Text<br> -------------<br> The fixed part of an OPT RR is structured as follows:<br> <br> +------------+--------------+---------= ---------------------+<br> | Field Name | Field Type = | Description &n= bsp; |<br> +------------+--------------+---------= ---------------------+<br> | NAME &n= bsp; | domain name | MUST be 0 (root domain) &= nbsp; |<br> | TYPE &n= bsp; | u_int16_t | OPT (41) = &nb= sp; |<br> | CLASS = | u_int16_t | requestor's UDP payload size |<br> | TTL &nb= sp; | u_int32_t | extended RCODE and flags &nb= sp; |<br> | RDLEN = | u_int16_t | length of all RDATA = |<br> | RDATA = | octet stream | {attribute,value} pairs |<br= > +------------+--------------+---------= ---------------------+<br> <br> Corrected Text<br> --------------<br> The fixed part of an OPT RR is structured as follows:<br> <br> +------------+--------------+---------= ---------------------+<br> | Field Name | Field Type = | Description &n= bsp; |<br> +------------+--------------+---------= ---------------------+<br> | NAME &n= bsp; | domain name | MUST be 0 (root domain) &= nbsp; |<br> | TYPE &n= bsp; | u_int16_t | OPT (41) = &nb= sp; |<br> | CLASS = | u_int16_t | sender's UDP payload size = |<br> | TTL &nb= sp; | u_int32_t | extended RCODE and flags &nb= sp; |<br> | RDLEN = | u_int16_t | length of all RDATA = |<br> | RDATA = | octet stream | {attribute,value} pairs |<br= > +------------+--------------+---------= ---------------------+<br> <br> Notes<br> -----<br> This restores the definition of EDNS0's OPT CLASS field as "sender's U= DP payload size" as it appeared in RFC 2671 rather than "requesto= r's UDP payload size" which appeared in RFC 6891 (specifically it appe= ars to have been introduced in draft-ietf-dnsext-rfc2671bis-edns0-02).<br> <br> 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 mes= sage, while the responder is the protocol endpoint that receives the DNS qu= ery message and sends the DNS response message. The requestor is the sender when it sends its DNS query message t= o the responder, and the responder is the sender when it sends its DNS resp= onse message to the requestor.<br> <br> 6891 specifically defines requestor/responder as:<br> <br> "Requestor" refers to the side that sends a request.= "Responder"<br> refers to an authoritative, recursive resolver or other DNS co= mponent<br> that responds to questions.<br> <br> 6891's definition of the OPT CLASS field as the "requestor's UDP paylo= ad size" thus literally means that the responder should copy the reque= stor's UDP payload size into the OPT CLASS field in the response message th= at the responder sends. There would then be no place in the packet for the responder to place the responder's UDP payl= oad 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 max= imum UDP payload sizes, for instance 6891 section 6.2.4:<br> <br> The responder's maximum payload size can change over time but = can<br> reasonably be expected to remain constant between two closely = spaced<br> sequential transactions, for example, an arbitrary QUERY used = as a<br> probe to discover a responder's maximum UDP payload size, foll= owed<br> immediately by an UPDATE that takes advantage of this size.<br= > <br> In practice, I believe modern EDNS0 responder implementations follow the ea= rlier definition from 2671 and the "requestor's UDP payload size"= definition in 6891 is a drafting mistake.<br> <br> Thanks!<br> <br> Instructions:<br> -------------<br> This erratum is currently posted as "Reported". (If it is spam, i= t <br> will be removed shortly by the RFC Production Center.) Please<br> use "Reply All" to discuss whether it should be verified or<br> rejected. When a decision is reached, the verifying party <br> will log in to change the status and edit the report, if necessary.<br> <br> --------------------------------------<br> RFC6891 (draft-ietf-dnsext-rfc2671bis-edns0-10)<br> --------------------------------------<br> Title &nbs= p; : Extension Mechanisms for DNS (EDNS(0))<br> Publication Date : April 2013<br> Author(s) : J. = Damas, M. Graff, P. Vixie<br> Category = : INTERNET STANDARD<br> Source &nb= sp; : DNS Extensions<br> Stream &nb= sp; : IETF<br> Verifying Party : IESG<o:p></o:p></span></p> </div> </div> </div> </div> </div> </body> </html> --_000_PH0PR11MB4966576F636A37C85A8AD845A9AC2PH0PR11MB4966namp_-- --===============7643922443604117641== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============7643922443604117641==--