Dear Kazunori and *Warren (AD), We have made your suggested update (see Appendix C.1). Please review the updated file and let us know if any further changes are needed or if you approve the document in its current form.
*Warren, please review the following update (removal of text) and let us know if you approve. The change is highlighted below and can also be viewed here: https://www.rfc-editor.org/authors/rfc9715-auth48diff.html. OLD: For R5, BIND 9 uses the edns-buf-size option, with the default of 1232. BIND 9 does implement R6. For R7, after two UDP timeouts, BIND 9 will fall back to TCP. NEW: For R5, BIND 9 uses the edns-buf-size option, with the default of 1232. For R7, after two UDP timeouts, BIND 9 will fall back to TCP. —Files (please refresh)— The updated XML file is here: https://www.rfc-editor.org/authors/rfc9715.xml The updated output files are here: https://www.rfc-editor.org/authors/rfc9715.txt https://www.rfc-editor.org/authors/rfc9715.pdf https://www.rfc-editor.org/authors/rfc9715.html This diff file shows all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9715-auth48diff.html These diff files show only the changes made during the last edit round: https://www.rfc-editor.org/authors/rfc9715-lastdiff.html https://www.rfc-editor.org/authors/rfc9715-lastrfcdiff.html (side by side) This diff file shows all changes made to date: https://www.rfc-editor.org/authors/rfc9715-diff.html Best regards, RFC Editor/kc > On Jan 21, 2025, at 12:54 AM, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: > > Dear RFC Editor, > > Current version is almost OK for me. > I would like to make an edit to remove one line. > > Please remove a line at Appendix C.1. > Current: BIND 9 does implement R6 (Section 3.2). > > I attach edited XML file. > > Regards, > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > >> From: Karen Moore <kmo...@staff.rfc-editor.org> >> Dear Kazunori and Paul, >> >> Thank you for your replies. We have updated our files based on your >> feedback. Note that we updated “EDNS0” to “EDNS(0)”and the recommendation >> numbers to reflect “R#”. Please review the changes (especially Appendix C.1 >> to ensure we updated the text as desired), and let us know if any further >> updates are needed or if you approve the document in its current form. >> >> —Files— >> >> The updated XML file is here: >> https://www.rfc-editor.org/authors/rfc9715.xml >> >> The updated output files are here: >> https://www.rfc-editor.org/authors/rfc9715.txt >> https://www.rfc-editor.org/authors/rfc9715.pdf >> https://www.rfc-editor.org/authors/rfc9715.html >> >> This diff file shows all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9715-auth48diff.html >> >> This diff file shows all changes made to date: >> https://www.rfc-editor.org/authors/rfc9715-diff.html >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. Please review the document carefully to ensure >> satisfaction as we do not make changes once it has been published as an RFC. >> >> We will await approvals from each author prior to moving forward in the >> publication process. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9715 >> >> Thank you, >> RFC Editor/kc >> >>> On Jan 16, 2025, at 2:20 AM, Kazunori Fujiwara via auth48archive >>> <auth48archive@rfc-editor.org> wrote: >>> >>> Dear RFC Editor, >>> >>> Thanks very much for your excellent rewrites. >>> >>> I will answer in-line as a first, quick response to proceed. >>> >>>> From: rfc-edi...@rfc-editor.org >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> 1) <!--[rfced] We have updated the short title that spans the header of >>>> the PDF file from "avoid-fragmentation" to "Avoid IP >>>> Fragmentation". Please review and let us know if any further >>>> changes are desired. >>>> >>>> Original: >>>> avoid-fragmentation >>>> >>>> Current: >>>> Avoid IP Fragmentation >>>> --> >>> >>> Agree. >>> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use on https://www.rfc-editor.org/search. --> >>> >>> I think "DNS" and "IP Fragmentation" are key words. >>> >>> Some RFCs that show attack countermeasures include "attack". >>> >>>> 3) <!--[rfced] How may we make these sentences clearer? Specifically, >>>> what does "other end" refer to in "keep it within the other end's >>>> MSS" - is it the other end of the segment? Also, does "as to how >>>> much queued data will fit" mean "depending on how much queued >>>> data will fit"? Please advise. >>>> >>>> Original: >>>> For each transmitted segment, the size of the IP and TCP >>>> headers is known, and the IP packet size can be chosen to >>>> keep it within the estimated MTU and the other end's MSS. >>>> This takes advantage of the elasticity of TCP's packetizing >>>> process as to how much queued data will fit into the next >>>> segment. >>>> >>>> Perhaps: >>>> For each transmitted segment, the size of the IP and TCP >>>> headers is known, and the IP packet size can be chosen to >>>> keep it within the estimated MTU and the MSS of the other >>>> end of the segment. This takes advantage of the elasticity >>>> of the TCP's packetizing process, depending on how much >>>> queued data will fit into the next segment. >>>> --> >>> >>> The proposed text is roughly fine, but I think it would be better to >>> delete "of the segment" from "the MSS of the other end of the >>> segment." >>> >>>> 4) <!-- [rfced] FYI: In Section 2, we placed the definitions that are >>>> direct quotes within the <blockquote> element, and we updated the >>>> text slightly to exactly match the quoted text in RFCs 6891 and 8201. >>>> Please review and let us know of any concerns. >>>> >>>> Original: >>>> "Requestor" refers to the side that sends a request. "Responder" >>>> refers to an authoritative server, recursive resolver or other DNS >>>> component that responds to questions. (Quoted from EDNS0 [RFC6891]) >>>> >>>> "Path MTU" is the minimum link MTU of all the links in a path between >>>> a source node and a destination node. (Quoted from [RFC8201]) >>>> >>>> Current: >>>> The definitions of "requestor" and "responder" are per [RFC6891]: >>>> >>>> "Requestor" refers to the side that sends a request. "Responder" >>>> refers to an authoritative, recursive resolver or other DNS >>>> component that responds to questions. >>>> >>>> The definition of "path MTU" is per [RFC8201]: >>>> >>>> path MTU [is] the minimum link MTU of all the links in a path >>>> between a source node and a destination node. >>>> --> >>> >>> Agree. >>> >>>> 5) <!--[rfced] Section 3.2. We find the use of "should/may" confusing. >>>> Is using only "should" or "may" acceptable? Please advise. >>>> >>>> Original: >>>> R6. UDP requestors should/may drop fragmented DNS/UDP responses >>>> without IP reassembly to avoid cache poisoning attacks (at >>>> firewall function). >>>> >>>> Perhaps: >>>> R6. UDP requestors may drop fragmented DNS/UDP responses without >>>> IP reassembly to avoid cache poisoning attacks (at the firewall >>>> function). >>>> --> >>> >>> This draft is "Informational". Then, ideally, please change to "should". >>> >>>> 6) <!-- [rfced] For clarity, may we update the following sentence as >>>> shown below since some of the text is a direct quote from RFC 8085? >>>> >>>> Current: >>>> In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines >>>> [RFC8085] we >>>> are told that an application SHOULD NOT send UDP datagrams that result in >>>> IP >>>> packets that exceed the Maximum Transmission Unit (MTU) along the path to >>>> the >>>> destination. >>>> >>>> Perhaps: >>>> Section 3.2 of [RFC8085] states that "an application SHOULD NOT send UDP >>>> datagrams that result in IP packets that exceed the Maximum Transmission >>>> Unit >>>> (MTU) along the path to the destination". >>>> --> >>> >>> Agree. >>> >>>> 7) <!-- [rfced] Informative Reference URLs >>>> >>>> a) We found the following URL for [Brandt2018]: >>>> https://dl.acm.org/doi/10.1145/3243734.3243790. >>>> May we update this reference to use this URL? >>>> >>>> Original: >>>> [Brandt2018] >>>> Brandt, M., Dai, T., Klein, A., Shulman, H., and M. Waidner, "Domain >>>> Validation++ For MitM-Resilient PKI", Proceedings of the 2018 ACM >>>> SIGSAC Conference on Computer and Communications Security , 2018. >>>> >>>> Perhaps: >>>> [Brandt2018] >>>> Brandt, M., Dai, T., Klein, A., Shulman, H., and M. >>>> Waidner, "Domain Validation++ For MitM-Resilient PKI", >>>> Proceedings of the 2018 ACM SIGSAC Conference on Computer >>>> and Communications Security, pp. 2060-2076, >>>> DOI 10.1145/3243734.3243790, October 2018, >>>> <https://dl.acm.org/doi/10.1145/3243734.3243790>. >>>> >>>> b) We found the following URL for [Herzberg2013]: >>>> https://ieeexplore.ieee.org/document/6682711. >>>> May we update this reference to use this URL? >>>> >>>> Original: >>>> [Herzberg2013] >>>> Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous", >>>> IEEE Conference on Communications and Network Security , 2013. >>>> >>>> Perhaps: >>>> [Herzberg2013] >>>> Herzberg, A. and H. Shulman, "Fragmentation Considered >>>> Poisonous, or: One-domain-to-rule-them-all.org", IEEE >>>> Conference on Communications and Network Security (CNS), >>>> DOI 10.1109/CNS.2013.6682711, 2013, >>>> <https://ieeexplore.ieee.org/document/6682711>. >>>> >>>> c) We found the following URL for [Fujiwara2018]: >>>> https://indico.dns-oarc.net/event/31/contributions/692/ >>>> attachments/660/1115/fujiwara-5.pdf. May we update this >>>> reference to use this URL? >>>> >>>> Original: >>>> [Fujiwara2018] >>>> Fujiwara, K., "Measures against cache poisoning attacks >>>> using IP fragmentation in DNS", OARC 30 Workshop , 2019. >>>> >>>> Perhaps: >>>> [Fujiwara2018] >>>> Fujiwara, K., "Measures against DNS cache poisoning attacks >>>> using IP fragmentation", OARC 30 Workshop, 2019, >>>> <https://indico.dns-oarc.net/event/31/contributions/692/ >>>> attachments/660/1115/fujiwara-5.pdf>. >>>> >>>> d) We found the following URL for [Huston2021]: >>>> https://indico.dns-oarc.net/event/37/contributions/806/ >>>> attachments/782/1366/2021-02-04-dns-flag.pdf. May we add >>>> this URL to the reference? >>>> >>>> Original: >>>> [Huston2021] >>>> Huston, G. and J. Damas, "Measuring DNS Flag Day 2020", >>>> OARC 34 Workshop , February 2021. >>>> >>>> Perhaps: >>>> [Huston2021] >>>> Huston, G. and J. Damas, "Measuring DNS Flag Day 2020", >>>> OARC 34 Workshop, February 2021, <https://indico.dns-oarc.net/ >>>> event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf> >>>> --> >>> >>> I agree all fixes. >>> >>>> 8) <!--[rfced] FYI: To match the quoted text in Section 3 of RFC 4035, we >>>> updated the text below to include a reference to RFC 2671, and we >>>> listed RFC 2671 as an informative reference. >>>> >>>> Original: >>>> [RFC4035] defines that "A security-aware name server MUST support >>>> the EDNS0 message size extension, MUST support a message >>>> size of at least 1220 octets". >>>> >>>> Current: >>>> [RFC4035] states that "A security-aware name server MUST support >>>> the EDNS0 ([RFC2671]) message size extension, [and it] MUST >>>> support a message size of at least 1220 octets". >>>> --> >>> >>> Agree. >>> >>>> 9) <!--[rfced] Regarding Appendix C ("Known Implementations"), is it your >>>> intention that this section remain in the RFC? The reason we ask >>>> is because RFC 7942 recommends removing it but also states that >>>> it is not mandatory to remove it. >>>> --> >>> >>> This document was changed from BCP to Informational due to >>> implementation concerns. I would like to keep Appendix C since it is >>> relevant in this situation. >>> >>>> 10) <!--[rfced] Since this document is "Informational", is it correct to >>>> state that this specification defines "best practices", or does >>>> this text need an update to avoid any confusion? >>>> >>>> Original: >>>> This section records the status of known implementations of these >>>> best practices defined by this specification at the time of >>>> publication, and any deviation from the specification. >>>> --> >>> >>> This part remains the same as when the intended status was BCP. >>> It is an oversight. >>> >>> Please change "best practices defined by this specification" >>> as "proposed recommendations described in Section 3". >>> >>>> 11) <!-- [rfced] Appendix C.1 >>>> >>>> a) We notice inconsistencies with the recommendation numbers, for example, >>>> "recommendation R6", "recommendation 2", and "R5". May we use "R#" for >>>> consistency below and throughout the document? Please let us know your >>>> preference. >>> >>> Authors intended R# to be unique and consistent in the document. >>> However, part of Appendix C were forgotten to be updated. >>> We need to refer draft-ietf-dnsop-avoid-fragmentation-12, >>> "Appendix D. Known Implementations" first appeared. >>> >>>> b) We find "the first recommendation of Section 3.2" and "recommendation 2 >>>> of Section 3.2" (which should be "R6") confusing. For clarity, may we add >>>> section numbers for the recommendation numbers that do not have them and >>>> update the text as shown below? >>> >>> Since R# is unique, the section number may not be necessary. >>> >>>> c) Please confirm if "recommendation 3" in the last entry is referring >>>> to R7 of Section 3.2. >>>> >>>> Original: >>>> BIND 9 does not implement the recommendations 1 and 2 in Section 3.1 >>>> >>>> For recommendation 3, BIND 9 will honor the requestor's size up to >>>> the configured limit (max-udp-size)... >>>> >>>> In the case of recommendation 4, and the send fails with EMSGSIZE, >>>> BIND 9 set the TC bit and try to send a minimal answer again. >>>> >>>> In the first recommendation of Section 3.2, BIND 9 uses the >>>> edns-buf-size option, with the default of 1232. >>>> >>>> BIND 9 does implement recommendation 2 of Section 3.2. >>>> >>>> For recommendation 3, after two UDP timeouts, BIND 9 will fall back >>>> to TCP. >>>> >>>> Perhaps: >>>> BIND 9 does not implement R1 and R2 in Section 3.1. >>> ^^^^^^^^^^^^^^^remove >>> >>>> For R3 (Section 3.1), BIND 9 will honor the requestor's size up to >>> ^^^^^^^^^^^^^remove >>>> the configured limit (max-udp-size)... >>>> >>>> In the case of R4 (Section 3.1) and the send fails with EMSGSIZE, >>> ^^^^^^^^^^^^^remove >>>> BIND 9 sets the TC bit and tries to send a minimal answer again. >>>> >>>> For R5 (Section 3.2), BIND 9 uses the edns-buf-size >>> ^^^^^^^^^^^^^remove >>>> option, with the default of 1232. >>>> >>>> BIND 9 does implement R6 (Section 3.2). >>> ^^^^^^^^^^^^^ remove >>>> For R7 (Section 3.2), after two UDP timeouts, BIND 9 will fall back >>> ^^^^^^^^^^^^^remove >>>> to TCP. >>>> >>>> c) How may we update this sentence for clarity? Does BIND 9 cause >>>> IP_DONTFRAG to be disabled? If so, may we add "When" as shown >>>> below? >>>> >>>> Original: >>>> BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is >>>> disabled. >>>> >>>> Perhaps: >>>> When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG >>>> is disabled. >>>> --> >>> >>> Agree. >>> >>>> 12) <!--[rfced] May we make the first three bulleted items into complete >>>> sentences for clarity? Also, is "Spoofing nearmisses" a specific >>>> term, or may we add a space to "nearmisses" per its dictionary >>>> spelling? And does this quoted term need a reference for >>>> background, or will readers be familiar with it? >>>> >>>> Original: >>>> * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT >>>> >>>> * default EDNS buffer size of 1232, no probing for smaller sizes >>>> >>>> * no handling of EMSGSIZE >>>> >>>> * Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing >>>> nearmisses" do. >>>> >>>> Perhaps: >>>> * Use IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT >>>> >>>> * The default EDNS buffer size is 1232; no probing for smaller sizes. >>>> >>>> * There is no handling of EMSGSIZE. >>>> >>>> * Recursor: UDP timeouts do not cause a switch to TCP; "Spoofing >>>> near misses" do. >>>> --> >>> >>> Agree. >>> >>>> 13) <!--[rfced] Please clarify what "if that is smaller" means as the >>>> text states that Unbound requests size 1232 and then it retries >>>> with a smaller size of 1232 for IPv6, which is confusing. Is the >>>> intended meaning perhaps that Unbound retries with a smaller size >>>> "if applicable"? Also, please clarify the intended meaning of >>>> "anything" in "This does not do anything". >>>> >>>> Additionally, should a citation be included for "flag day", either >>>> [DNSFlagDay2020] or [Huston2021], for easy reference? >>>> >>>> Note that the preceding sentence is included for context. >>>> >>>> Original: >>>> Unbound requests UDP size 1232 from peers, by default. The >>>> requestors size is limited to a max of 1232. >>>> >>>> After some timeouts, Unbound retries with a smaller size, if that is >>>> smaller, at size 1232 for IPv6 and 1472 for IPv4. This does not do >>>> anything since the flag day change to 1232. >>>> >>>> Perhaps: >>>> Unbound requests a UDP size of 1232 from peers, by default. The >>>> requestor's size is limited to a max of 1232. >>>> >>>> After some timeouts, Unbound retries with a smaller size, if applicable, >>>> or at size 1232 for IPv6 and 1472 for IPv4. This does not cause any >>>> negative effects due to the "flag day" [DNSFlagDay2020] change to 1232. >>>> --> >>> >>> Agree. >>> >>>> 14) <!--[rfced] May we update this sentence as follows for clarity? >>>> >>>> Original: >>>> Unbound has minimal responses as an option, default on. >>>> >>>> Perhaps: >>>> Unbound has the 'minimal responses' configuration option; set >>>> default on. >>>> --> >>> >>> Agree. >>> >>>> 15) <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is >>>> output in >>>> fixed-width font. In the txt output, there are no changes to the font, >>>> and the quotation marks have been removed. >>>> >>>> Please review carefully and let us know if the output is acceptable or if >>>> any >>>> updates are needed. >>>> --> >>> >>> I will check this next revision. >>> >>>> 16) <!-- [rfced] Terminology >>>> >>>> a) Throughout the text, the following terminology appears to be used >>>> inconsistently. Please review these occurrences and let us know if/how they >>>> may be made consistent. >>>> >>>> Don't Fragment flag (DF) bit vs. Don't Fragment (DF) bit >>>> [Note: Should this be "Don't Fragment (DF) flag bit" >>>> per RFC 0791?] >>>> >>>> More Fragments (MF) bit >>>> [Note: Should this be "More Fragments (MF) flag bit" >>>> for consistency?] >>> >>> Yes. Please choose RFC 0791 style. >>> >>>> b) We made the following updates for consistency. Please let us know of >>>> any objections. >>>> >>>> Additional Section -> Additional section (per RFCs 1035 and 9460) >>>> [Note: RFC 2782 uses "Additional Data section"; please let >>>> us know if the current text is okay or if it should include >>>> "data".] >>>> >>>> Path MTU discovery -> Path MTU Discovery (per RFC 8201) >>>> Path MTU -> path MTU (per RFC 8201) >>>> --> >>> >>> Agree. >>> >>>> 17) <!-- [rfced] Abbreviations >>>> >>>> a) FYI - We have added expansions for the following abbreviations >>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>> expansion in the document carefully to ensure correctness. >>>> >>>> Elliptic Curve Digital Signature Algorithm (ECDSA) >>>> Edwards-curve Digital Signature Algorithm (EdDSA) >>>> Service Binding (SVCB) >>>> Resource Record (RR) >>> >>> OK for me. >>> >>>> b) We notice that this document as well as RFCs 8900 and 9471 use >>>> "EDNS0" but RFC 6891 uses "EDNS(0)". Please let us know if using >>>> "EDNS0" is preferred or if you would like to use "EDNS(0)". >>>> >>>> Current: >>>> Extension Mechanisms for DNS (EDNS0) >>>> >>>> Perhaps: >>>> Extension Mechanisms for DNS (EDNS(0)) >>> >>> Both are OK for me. >>> need to discuss with co-author. >>> >>>> c) We do not see "XDP" used in any other RFCs. Does "XDP" stand for >>>> something >>>> (i.e., can it be expanded)? >>>> >>>> Current: >>>> Fragments are ignored if they arrive over an XDP interface. >>>> --> >>> >>> This section contains verbatim text from each implementer, >>> so there may be some inconsistencies in the text. >>> Regarding XDP, how about "Linux XDP" ? >>> >>>> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online >>>> Style Guide >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>> and let us know if any changes are needed. Updates of this nature >>>> typically >>>> result in more precise language, which is helpful for readers. >>>> >>>> Note that our script did not flag any words in particular, but this should >>>> still be reviewed as a best practice. >>>> --> >>> >>> I will need to work next weeks... >>> But now, I could not retrieve NIST document now. >>> https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf >>> -> 503 Service Unavailable >>> >>> >>> Regards, >>> >>> -- >>> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >>> >>> >>>> Thank you. >>>> >>>> RFC Editor/kc >>>> >>>> >>>> On Jan 13, 2025, at 6:41 PM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2025/01/13 >>>> >>>> RFC Author(s): >>>> -------------- >>>> >>>> Instructions for Completing AUTH48 >>>> >>>> Your document has now entered AUTH48. Once it has been reviewed and >>>> approved by you and all coauthors, it will be published as an RFC. >>>> If an author is no longer available, there are several remedies >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>> >>>> You and you coauthors are responsible for engaging other parties >>>> (e.g., Contributors or Working Group) as necessary before providing >>>> your approval. >>>> >>>> Planning your review >>>> --------------------- >>>> >>>> Please review the following aspects of your document: >>>> >>>> * RFC Editor questions >>>> >>>> Please review and resolve any questions raised by the RFC Editor >>>> that have been included in the XML file as comments marked as >>>> follows: >>>> >>>> <!-- [rfced] ... --> >>>> >>>> These questions will also be sent in a subsequent email. >>>> >>>> * Changes submitted by coauthors >>>> >>>> Please ensure that you review any changes submitted by your >>>> coauthors. We assume that if you do not speak up that you >>>> agree to changes submitted by your coauthors. >>>> >>>> * Content >>>> >>>> Please review the full content of the document, as this cannot >>>> change once the RFC is published. Please pay particular attention to: >>>> - IANA considerations updates (if applicable) >>>> - contact information >>>> - references >>>> >>>> * Copyright notices and legends >>>> >>>> Please review the copyright notice and legends as defined in >>>> RFC 5378 and the Trust Legal Provisions >>>> (TLP – https://trustee.ietf.org/license-info). >>>> >>>> * Semantic markup >>>> >>>> Please review the markup in the XML file to ensure that elements of >>>> content are correctly tagged. For example, ensure that <sourcecode> >>>> and <artwork> are set correctly. See details at >>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * Formatted output >>>> >>>> Please review the PDF, HTML, and TXT files to ensure that the >>>> formatted output, as generated from the markup in the XML file, is >>>> reasonable. Please note that the TXT will have formatting >>>> limitations compared to the PDF and HTML. >>>> >>>> >>>> Submitting changes >>>> ------------------ >>>> >>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>> the parties CCed on this message need to see your changes. The parties >>>> include: >>>> >>>> * your coauthors >>>> >>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>> >>>> * other document participants, depending on the stream (e.g., >>>> IETF Stream participants are your working group chairs, the >>>> responsible ADs, and the document shepherd). >>>> >>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>> to preserve AUTH48 conversations; it is not an active discussion >>>> list: >>>> >>>> * More info: >>>> >>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * Note: If only absolutely necessary, you may temporarily opt out >>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>> If needed, please add a note at the top of the message that you >>>> have dropped the address. When the discussion is concluded, >>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>> its addition will be noted at the top of the message. >>>> >>>> You may submit your changes in one of two ways: >>>> >>>> An update to the provided XML file >>>> — OR — >>>> An explicit list of changes in this format >>>> >>>> Section # (or indicate Global) >>>> >>>> OLD: >>>> old text >>>> >>>> NEW: >>>> new text >>>> >>>> You do not need to reply with both an updated XML file and an explicit >>>> list of changes, as either form is sufficient. >>>> >>>> We will ask a stream manager to review and approve any changes that seem >>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>> and technical changes. Information about stream managers can be found in >>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>> >>>> >>>> Approving for publication >>>> -------------------------- >>>> >>>> To approve your RFC for publication, please reply to this email stating >>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>> as all the parties CCed on this message need to see your approval. >>>> >>>> >>>> Files >>>> ----- >>>> >>>> The files are available here: >>>> https://www.rfc-editor.org/authors/rfc9715.xml >>>> https://www.rfc-editor.org/authors/rfc9715.html >>>> https://www.rfc-editor.org/authors/rfc9715.pdf >>>> https://www.rfc-editor.org/authors/rfc9715.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9715-diff.html >>>> https://www.rfc-editor.org/authors/rfc9715-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9715-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9715 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9715 (draft-ietf-dnsop-avoid-fragmentation-20) >>>> >>>> Title : IP Fragmentation Avoidance in DNS over UDP >>>> Author(s) : K. Fujiwara, P. Vixie >>>> WG Chair(s) : Suzanne Woolf, Benno Overeinder, Tim Wicinski >>>> >>>> Area Director(s) : Warren Kumari, Mahesh Jethanandani >>>> >>>> >>>> >>> -- >>> auth48archive mailing list -- auth48archive@rfc-editor.org >>> To unsubscribe send an email to auth48archive-le...@rfc-editor.org >> >> > <?xml version='1.0' encoding='UTF-8'?> > > <!-- pre-edited by ST 10/01/24 --> > <!-- formatted by ST 11/08/24 --> > <!-- reference review by TH 11/25/24 --> > > <!DOCTYPE rfc [ > <!ENTITY nbsp " "> > <!ENTITY zwsp "​"> > <!ENTITY nbhy "‑"> > <!ENTITY wj "⁠"> > ]> > > <rfc xmlns:xi="http://www.w3.org/2001/XInclude"; ipr="trust200902" > docName="draft-ietf-dnsop-avoid-fragmentation-20" number="9715" > category="info" consensus="true" submissionType="IETF" tocDepth="4" > tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" updates="" > version="3" xml:lang="en"> > > <front> > <title abbrev="Avoid IP Fragmentation">IP Fragmentation Avoidance in DNS > over UDP</title> > <seriesInfo name="RFC" value="9715"/> > <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara"> > <organization abbrev="JPRS">Japan Registry Services Co., > Ltd.</organization> > <address> > <postal> > <street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street> > <region>Chiyoda-ku, Tokyo</region> > <code>101-0065</code> > <country>Japan</country> > </postal> > <phone>+81 3 5215 8451</phone> > <email>fujiw...@jprs.co.jp</email> > </address> > </author> > <author initials="P." surname="Vixie" fullname="Paul Vixie"> > <organization>AWS Security</organization> > <address> > <postal> > <street>11400 La Honda Road</street> > <city>Woodside</city> > <region>CA</region> > <code>94062</code> > <country>United States of America</country> > </postal> > <phone>+1 650 393 3994</phone> > <email>p...@redbarn.org</email> > </address> > </author> > <date year="2025" month="January"/> > <area>OPS</area> > <workgroup>dnsop</workgroup> > > <abstract> > <t>The widely > deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a > DNS receiver to indicate > its received UDP message size capacity, which supports the sending of > large UDP responses by a DNS server. > Large DNS/UDP messages are more likely to be fragmented, > and IP fragmentation has exposed weaknesses in application protocols. > It is possible to avoid IP fragmentation in DNS by limiting the response > size where possible and signaling the need to upgrade from UDP to TCP > transport where necessary. > This document describes techniques to avoid IP fragmentation in DNS.</t> > </abstract> > </front> > <middle> > <?line 142?> > > <section anchor="introduction"> > <name>Introduction</name> > <t>This document was originally intended to be a Best Current Practice, > but due to > operating system and socket option limitations, some of the > recommendations have not yet gained real-world experience; > therefore, this document is Informational. > It is expected that, as operating systems and implementations evolve, > we will gain more experience with the recommendations and will publish an > updated document as a Best Current Practice in the future.</t> > <t>DNS has an EDNS(0) mechanism <xref target="RFC6891"/>. > The widely deployed EDNS(0) feature in the DNS enables a DNS receiver to > indicate > its received UDP message size capacity, which supports the sending of > large UDP responses by a DNS server. > DNS over UDP invites IP fragmentation when a packet is larger than the > Maximum Transmission Unit (MTU) of some network in the packet's path.</t> > <t>Fragmented DNS UDP responses have systemic weaknesses, which expose > the requestor to DNS cache poisoning from off-path attackers (see <xref > target="ProblemOfFragmentation"/> for references and details).</t> > <t><xref target="RFC8900"/> states that IP fragmentation > introduces fragility to Internet communication. > The transport of DNS messages > over UDP should take account of the observations stated in that document.</t> > <t>TCP avoids fragmentation by segmenting data into packets that are > smaller > than or equal to the Maximum Segment Size (MSS). For each transmitted > segment, the size of the IP and TCP headers is known, > and the IP packet size can be chosen to keep it within the estimated MTU and > the MSS. This takes advantage of the elasticity of the TCP's > packetizing process, depending on how much queued data will fit into the next > segment. In contrast, DNS over UDP has little datagram size elasticity and > lacks insight into IP header and option size, so we must make more > conservative estimates about available UDP payload space.</t> > <t><xref target="RFC7766"/> states that all general-purpose DNS > implementations <bcp14>MUST</bcp14> support both UDP and TCP > transport.</t> > > <t>DNS transaction security <xref target="RFC8945"/> <xref > target="RFC2931"/> does protect > against the security risks of fragmentation, and it protects > delegation responses. But <xref target="RFC8945"/> has limited applicability > due > to key distribution requirements, and there is little if any deployment > of <xref target="RFC2931"/>.</t> > <t>This document describes various techniques to avoid IP fragmentation > of UDP packets in DNS. > This document is primarily applicable to DNS use on the global Internet.</t> > <t>In contrast, a path MTU that deviates from the > recommended value might be obtained through static configuration, server > routing hints, or a future discovery protocol. However, addressing > this falls outside the scope of this document and may be the subject > of future specifications.</t> > </section> > <section anchor="terminology"> > <name>Terminology</name> > <t> > The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", > "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL > NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", > "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", > "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are > to be interpreted as > described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> > when, and only when, they appear in all capitals, as shown here. > </t> > > <t>The definitions of "requestor" and "responder" are per <xref > target="RFC6891"/>:</t> > > <blockquote> > "Requestor" refers to the side that sends a request. "Responder" > refers to an authoritative, recursive resolver or other DNS component > that responds to questions.</blockquote> > > <t>The definition of "path MTU" is per <xref target="RFC8201"/>:</t> > <blockquote>path MTU [is] the minimum link MTU of all the links in a path > between a source node and a destination node.</blockquote> > > <t>In this document, the term "Path MTU Discovery" includes > both Classical Path MTU Discovery <xref target="RFC1191"/> <xref > target="RFC8201"/> and > Packetization Layer Path MTU Discovery <xref target="RFC8899"/>.</t> > <t>Many of the specialized terms used in this document are defined in > "DNS Terminology" <xref target="RFC9499"/>.</t> > </section> > <section anchor="recommendation"> > <name>How to Avoid IP Fragmentation in DNS</name> > <t>These recommendations are intended > for nodes with global IP addresses on the Internet. > Private networks or local networks are out of the scope of this document.</t> > <t>The methods to avoid IP fragmentation in DNS are described below:</t> > <section anchor="RecommendationsResponders"> > <name>Proposed Recommendations for UDP Responders</name> > <dl spacing="normal" newline="false" indent="7"> > <dt>R1.</dt><dd>UDP responders should not use IPv6 fragmentation > <xref target="RFC8200"/>.</dd> > <dt>R2.</dt><dd><t>UDP responders should configure their systems to > prevent fragmentation of UDP packets when sending replies, provided > it can be done safely. The mechanisms to achieve this vary across > different operating systems.</t> > > <t>For BSD-like operating systems, the IP Don't Fragment (DF) flag > bit <xref target="RFC0791"/> can be used to prevent > fragmentation. In contrast, Linux systems do not expose a direct API > for this purpose and require the use of Path MTU socket options > (IP_MTU_DISCOVER) to manage fragmentation settings. However, it is > important to note that enabling IPv4 Path MTU Discovery for UDP in > current Linux versions is considered harmful and dangerous. For more > details, see <xref target="impl"/>.</t></dd> > <dt>R3.</dt><dd>UDP responders should compose response packets that > fit in the minimum of the offered requestor's maximum UDP payload > size <xref target="RFC6891"/>, the interface MTU, the network MTU > value configured by the knowledge of the network operators, and the > <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. For > more details, see > <xref target="details"/>.</dd> > <dt>R4.</dt><dd>If the UDP responder detects an immediate error > indicating that the UDP packet exceeds the path MTU size, the UDP > responder may recreate response packets that fit in the path MTU > size or with the TC bit set.</dd> > </dl> > <t>The cause and effect of the TC bit are unchanged <xref > target="RFC1035"/>.</t> > </section> > <section anchor="RecommendationsRequestors"> > <name>Proposed Recommendations for UDP Requestors</name> > <dl spacing="normal" newline="false" indent="7"> > <dt>R5.</dt><dd>UDP requestors should limit the requestor's maximum > UDP payload size to fit in the minimum of the interface MTU, the > network MTU value configured by the network operators, and the > <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. A > smaller limit may be allowed. For more details, see <xref > target="details"/>.</dd> > > <dt>R6.</dt><dd>UDP requestors should drop fragmented DNS/UDP > responses without IP reassembly to avoid cache poisoning attacks (at > the firewall function).</dd> > <dt>R7.</dt><dd>DNS responses may be dropped by IP fragmentation. > It is recommended that requestors eventually try alternative > transport protocols.</dd> > </dl> > </section> > </section> > <section anchor="RecommendationOperators"> > <name>Proposed Recommendations for DNS Operators</name> > <t>Large DNS responses are typically the result of zone configuration. > People who publish information in the DNS should seek configurations > resulting in small responses. For example:</t> > <dl spacing="normal" newline="false" indent="7"> > <dt>R8.</dt><dd>Use a smaller number of name servers.</dd> > <dt>R9.</dt><dd>Use a smaller number of A/AAAA RRs for a domain > name.</dd> > <dt>R10.</dt><dd>Use minimal-responses configuration: Some > implementations have a 'minimal responses' configuration option that > causes DNS servers to make response packets smaller by containing only > mandatory and required data (<xref target="minimal-responses"/>).</dd> > <dt>R11.</dt><dd>Use a smaller signature / public key size algorithm > for DNSSEC. Notably, the signature sizes of the Elliptic Curve Digital > Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm > (EdDSA) are > smaller than those of equivalent cryptographic strength using RSA.</dd> > </dl> > <t>It is difficult to determine a specific upper limit for R8, R9, and > R11, but it is sufficient if all responses from the DNS servers are > below the size of R3 and R5.</t> > </section> > <section anchor="protocol"> > <name>Protocol Compliance Considerations</name> > <t>Some authoritative servers deviate from the DNS standard as > follows:</t> > <ul spacing="normal"> > <li> > <t>Some authoritative servers ignore the EDNS(0) requestor's maximum > UDP payload size and return large UDP responses <xref > target="Fujiwara2018"/>.</t> > </li> > <li> > <t>Some authoritative servers do not support TCP transport.</t> > </li> > </ul> > <t>Such non-compliant behavior cannot become implementation or > configuration > constraints for the rest of the DNS. If failure is the result, then that > failure must be localized to the non-compliant servers.</t> > </section> > <section anchor="iana"> > <name>IANA Considerations</name> > <t>This document has no IANA actions.</t> > </section> > <section anchor="securitycons"> > <name>Security Considerations</name> > <section anchor="on-path-fragmentation-on-ipv4"> > <name>On-Path Fragmentation on IPv4</name> > <t>If the Don't Fragment (DF) flag bit is not set, > on-path fragmentation may happen on IPv4, > and it can lead to vulnerabilities as shown in <xref > target="ProblemOfFragmentation"/>. > To avoid this, R6 needs to be used to discard the fragmented responses and > retry using TCP.</t> > </section> > <section anchor="small-mtu-network"> > <name>Small MTU Network</name> > <t>When avoiding fragmentation, > a DNS/UDP requestor behind a small MTU network may experience > UDP timeouts, which would reduce performance > and may lead to TCP fallback. > This would indicate prior reliance upon IP fragmentation, > which is considered to be harmful > to both the performance and stability of applications, endpoints, and > gateways. > Avoiding IP fragmentation will improve operating conditions overall, > and the performance of DNS/TCP has increased and will continue to > increase.</t> > <t>If a UDP response packet is dropped in transit, > up to and including the network stack of the initiator, > it increases the attack window for poisoning the requestor's cache.</t> > </section> > <section anchor="ProblemOfFragmentation"> > <name>Weaknesses of IP Fragmentation</name> > <t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"/> > notes effective > off-path DNS cache poisoning attack vectors using IP fragmentation. > "IP fragmentation attack on DNS" <xref target="Hlavacek2013"/> and "Domain > Validation++ > For MitM-Resilient PKI" <xref target="Brandt2018"/> note that off-path > attackers > can intervene in the Path MTU Discovery <xref target="RFC1191"/> > to cause authoritative servers to produce fragmented responses. > <xref target="RFC7739"/> states the > security implications of predictable fragment identification values.</t> > > <t><xref section="3.2" sectionFormat="of" target="RFC8085"/> states > that > "an application <bcp14>SHOULD NOT</bcp14> send UDP datagrams > that result in IP packets that exceed the Maximum Transmission Unit (MTU) > along the path to the destination".</t> > <t>A DNS message receiver cannot trust fragmented UDP datagrams > primarily due to > the small amount of entropy provided by UDP port numbers and DNS message > identifiers, each of which is only 16 bits in size, and both are likely > to be in the first fragment of a packet if fragmentation occurs. > By comparison, the TCP protocol stack controls packet size and avoids IP > fragmentation under ICMP NEEDFRAG attacks. > In TCP, fragmentation should be avoided for performance reasons, whereas for > UDP, fragmentation should be avoided for resiliency and authenticity > reasons.</t> > </section> > <section anchor="dns-security-protections"> > <name>DNS Security Protections</name> > <t>DNSSEC is a countermeasure against cache poisoning attacks that use > IP fragmentation. > However, DNS delegation responses are not signed with DNSSEC, > and DNSSEC does not have a mechanism to get the correct response if > an incorrect delegation is injected. This is a denial-of-service > vulnerability that can yield failed name resolutions. > If cache poisoning attacks can be avoided, > DNSSEC validation failures will be avoided.</t> > </section> > <section anchor="possible-actions-for-resolver-operators"> > <name>Possible Actions for Resolver Operators</name> > <t>Because this document is published as Informational > rather than a Best Current Practice, > this section presents steps that resolver operators can take > to avoid vulnerabilities related to IP fragmentation.</t> > <t>To avoid vulnerabilities related to IP fragmentation, > implement R5 and R6.</t> > > <t>Specifically, configure the firewall functions protecting the > full-service resolver > to discard incoming DNS response packets > with a non-zero Fragment Offset (FO) or a More Fragments (MF) flag bit of 1 > on IPv4, > and discard packets with IPv6 Fragment Headers. > (If the resolver's IP address is not dedicated to the DNS resolver > and uses UDP communication that relies on IP Fragmentation for purposes > other than DNS, discard only the first fragment that contains the UDP header > from port 53.)</t> > <t>The most recent resolver software is believed to implement R7.</t> > <t>Even if R7 is not implemented, it will only result in a name > resolution error, > preventing attacks from leading to malicious sites.</t> > </section> > </section> > </middle> > <back> > <references> > <name>References</name> > <references anchor="sec-normative-references"> > <name>Normative References</name> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7739.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/> > </references> > <references anchor="sec-informative-references"> > <name>Informative References</name> > > <reference anchor="Brandt2018" > target="https://dl.acm.org/doi/10.1145/3243734.3243790";> > <front> > <title>Domain Validation++ For MitM-Resilient PKI</title> > <author initials="M." surname="Brandt" fullname="Markus Brandt"> > <organization>Fraunhofer Institute for Secure Information > Technology SIT, Darmstadt, Germany</organization> > </author> > <author initials="T." surname="Dai" fullname="Tianxiang Dai"> > <organization>Fraunhofer Institute for Secure Information > Technology SIT, Darmstadt, Germany</organization> > </author> > <author initials="A." surname="Klein" fullname="Amit Klein"> > <organization>Fraunhofer Institute for Secure Information > Technology SIT, Darmstadt, Germany</organization> > </author> > <author initials="H." surname="Shulman" fullname="Haya Shulman"> > <organization>Fraunhofer Institute for Secure Information > Technology SIT, Darmstadt, Germany</organization> > </author> > <author initials="M." surname="Waidner" fullname="Michael Waidner"> > <organization>Fraunhofer Institute for Secure Information > Technology SIT, Darmstadt, Germany</organization> > </author> > <date month="October" year="2018"/> > </front> > <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on > Computer and Communications Security, pp. 2060-2076</refcontent> > <seriesInfo name="DOI" value="10.1145/3243734.3243790"/> > </reference> > > <reference anchor="Herzberg2013" > target="https://ieeexplore.ieee.org/document/6682711";> > <front> > <title>Fragmentation Considered Poisonous, or: > One-domain-to-rule-them-all.org</title> > <author initials="A." surname="Herzberg" fullname="Amir Herzberg"> > <organization/> > </author> > <author initials="H." surname="Shulman" fullname="Haya Shulman"> > <organization/> > </author> > <date year="2013"/> > </front> > <refcontent>IEEE Conference on Communications and Network Security > (CNS)</refcontent> > <seriesInfo name="DOI" value="10.1109/CNS.2013.6682711"/> > </reference> > > <reference anchor="Hlavacek2013" > target="https://ripe67.ripe.net/presentations/240-ipfragattack.pdf";> > <front> > <title>IP fragmentation attack on DNS</title> > <author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek"> > <organization>cz.nic</organization> > </author> > <date year="2013"/> > </front> > <refcontent>RIPE 67 Meeting</refcontent> > </reference> > > <reference anchor="Fujiwara2018" > target="https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf";> > <front> > <title>Measures against DNS cache poisoning attacks using IP > fragmentation</title> > <author initials="K." surname="Fujiwara" fullname="Kazunori > Fujiwara"> > <organization>JPRS</organization> > </author> > <date year="2019"/> > </front> > <refcontent>OARC 30 Workshop</refcontent> > </reference> > > <reference anchor="DNSFlagDay2020" > target="https://dnsflagday.net/2020/";> > <front> > <title>DNS flag day 2020</title> > <author> > <organization/> > </author> > <date></date> > </front> > </reference> > > <reference anchor="Huston2021" > target="https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf";> > <front> > <title>Measuring DNS Flag Day 2020</title> > <author initials="G." surname="Huston" fullname="Geoff Huston"> > <organization>APNIC Labs</organization> > </author> > <author initials="J." surname="Damas" fullname="Joao Damas"> > <organization>APNIC Labs</organization> > </author> > <date year="2021" month="February"/> > </front> > <refcontent>OARC 34 Workshop</refcontent> > </reference> > > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9471.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/> > <xi:include > href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2671.xml"/> > > </references> > </references> > > <section anchor="details"> > <name>Details of Requestor's Maximum UDP Payload Size Discussions</name> > <t>There are many discussions about default path MTU size and a > requestor's maximum UDP payload size.</t> > <ul spacing="normal"> > <li> > <t>The minimum MTU for an IPv6 interface is 1280 octets > (see <xref section="5" sectionFormat="of" target="RFC8200"/>). > So, it can be used as the default path MTU value for IPv6. > The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8) > <xref target="RFC0791"/>.</t> > </li> > <li> > > <t><xref target="RFC4035"/> states that "A security-aware name > server <bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) > message size extension, [and it] <bcp14>MUST</bcp14> support a message size > of at least 1220 octets". Then, the smallest number of > the maximum DNS/UDP payload size is 1220.</t> > </li> > <li> > <t>In order to avoid IP fragmentation, > <xref target="DNSFlagDay2020"/> proposes that UDP requestors set the > requestor's > payload size to 1232 and UDP responders compose UDP responses so they fit > in 1232 octets. > The size 1232 is based on an MTU of 1280, which is required > by the IPv6 specification <xref target="RFC8200"/>, > minus 48 octets for the IPv6 and UDP headers.</t> > </li> > <li> > <t>Most of the Internet, especially the inner core, has an MTU of at > least > 1500 octets. > Maximum DNS/UDP payload size for IPv6 on an MTU 1500 Ethernet is > 1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)). > To allow for possible IP options and distant tunnel overhead, > the recommendation of default maximum DNS/UDP payload size is 1400.</t> > </li> > <li> > <t><xref target="Huston2021"/> analyzes the result of <xref > target="DNSFlagDay2020"/> and reports that > their measurements suggest that in the interior of the Internet > between recursive resolvers and authoritative servers, the prevailing MTU is > 1500 > and there is no measurable signal of use of smaller MTUs > in this part of the Internet. They propose that > their measurements suggest setting the EDNS(0) requestor's UDP payload size to > 1472 octets for IPv4 and 1452 octets for IPv6.</t> > </li> > </ul> > <t>As a result of these discussions, > this document recommends a value of 1400, > with smaller values also allowed.</t> > </section> > <section anchor="minimal-responses"> > <name>Minimal Responses</name> > <t>Some implementations have a "minimal responses" configuration > setting/option that causes > a DNS server to make response packets smaller, containing only mandatory and > required data.</t> > > <t>Under the minimal-responses configuration, > a DNS server composes responses containing only necessary Resource Records > (RRs). > For delegations, see <xref target="RFC9471"/>. > In case of a non-existent domain name or non-existent type, > the authority section will contain an SOA record, and the answer section is > empty > (see <xref section="2" sectionFormat="of" target="RFC2308"/>).</t> > <t>Some resource records (MX, SRV, SVCB, and HTTPS) require > additional A, AAAA, and Service Binding (SVCB) records > in the Additional section > defined in <xref target="RFC1035"/>, <xref target="RFC2782"/>, and <xref > target="RFC9460"/>.</t> > <t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC > OK bit, > signatures are added in the answer section, > or the corresponding DS RRSet and signatures are added in the authority > section. > Details are defined in <xref target="RFC4035"/> and <xref > target="RFC5155"/>.</t> > </section> > <section anchor="impl"> > <name>Known Implementations</name> > > <t>This section records the status of known implementations of the > proposed recommendations described in <xref target="recommendation"/>.</t> > <t>Please note that the listing of any individual implementation here > does not > imply endorsement by the IETF. Furthermore, no effort has been made to > verify the information that was supplied by IETF contributors and presented > here.</t> > <section anchor="bind-9"> > > <name>BIND 9</name> > <t>BIND 9 does not implement R1 and R2. <!--<xref > target="RecommendationsResponders"/>--></t> > <t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a > fallback to > IP_PMTUDISC_DONT.</t> > > <t>When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), > IP_DONTFRAG is disabled.</t> > <t>Accepting Path MTU Discovery for UDP is considered harmful and > dangerous. > BIND 9's settings avoid attacks to Path MTU Discovery.</t> > <t>For R3, BIND 9 will honor the requestor's size up to the > configured limit (<tt>max-udp-size</tt>). The UDP response packet is bound to > be > between 512 and 4096 bytes, with the default set to 1232. BIND 9 supports the > requestor's size up to the configured limit (<tt>max-udp-size</tt>).</t> > <t>In the case of R4 and the send fails with EMSGSIZE, BIND 9 > sets the TC bit and tries to send a minimal answer again.</t> > <t>For R5, <!--<xref target="RecommendationsRequestors"/>--> BIND 9 > uses the <tt>edns-buf-size</tt> > option, with the default of 1232.</t> > <!-- remove this (by fujiwara): <t>BIND 9 does implement R6.--> <!--<xref > target="RecommendationsRequestors"/>--><!-- </t> --> > <t>For R7, after two UDP timeouts, BIND 9 will fall back to TCP.</t> > </section> > <section anchor="knot-dns-and-knot-resolver"> > <name>Knot DNS and Knot Resolver</name> > <t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. > The UDP size limit is 1232 by default.</t> > <t>Fragments are ignored if they arrive over a Linux XDP interface.</t> > <t>TCP is attempted after repeated UDP timeouts.</t> > <t>Minimal responses are returned and are currently not > configurable.</t> > <t>Smaller signatures are used, with ecdsap256sha256 as the > default.</t> > </section> > <section > anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdist"> > <name>PowerDNS Authoritative Server, PowerDNS Recursor, and PowerDNS > dnsdist</name> > > <ul spacing="normal"> > <li> > <t>Use IP_PMTUDISC_OMIT with a fallback to IP_PMTUDISC_DONT.</t> > </li> > <li> > <t>The default EDNS buffer size of 1232; no probing for smaller > sizes.</t> > </li> > <li> > <t>There is no handling of EMSGSIZE.</t> > </li> > <li> > <t>Recursor: UDP timeouts do not cause a switch to TCP, but > "spoofing near misses" may.</t> > </li> > </ul> > </section> > <section anchor="powerdns-authoritative-server"> > <name>PowerDNS Authoritative Server</name> > <ul spacing="normal"> > <li> > <t>The default DNSSEC algorithm is 13.</t> > </li> > <li> > <t>Responses are minimal; this is not configurable.</t> > </li> > </ul> > </section> > <section anchor="unbound"> > <name>Unbound</name> > <t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to > IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have > it, but not on Apple systems. On systems that support it, Unbound sets > IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback > to IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT, > with a fallback to IPV6_PMTUDISC_DONT.</t> > <t>Unbound requests a UDP size of 1232 from peers, by default. The > requestor's > size is limited to a max of 1232.</t> > > > <t>After some timeouts, Unbound retries with a smaller size, if > applicable, or at > size 1232 for IPv6 and 1472 for IPv4. This does not cause any negative > effects due to > the "flag day" <xref target="DNSFlagDay2020"/> change to 1232.</t> > > > <t>Unbound has the "minimal responses" configuration option; set > default on.</t> > </section> > <section anchor="acknowledgments" numbered="false"> > <name>Acknowledgments</name> > <t>The authors would like to specifically thank <contact fullname="Paul > Wouters"/>, <contact fullname="Mukund Sivaraman"/>, <contact > fullname="Tony Finch"/>, <contact fullname="Hugo Salgado"/>, <contact > fullname="Peter van Dijk"/>, <contact fullname="Brian Dickson"/>, > <contact fullname="Puneet Sood"/>, <contact fullname="Jim Reid"/>, > <contact fullname="Petr Spacek"/>, <contact fullname="Andrew > McConachie"/>, <contact fullname="Joe Abley"/>, <contact > fullname="Daisuke Higashi"/>, <contact fullname="Joe Touch"/>, <contact > fullname="Wouter Wijngaards"/>, <contact fullname="Vladimir Cunat"/>, > <contact fullname="Benno Overeinder"/>, and <contact fullname="Štěpán > Němec"/> for their extensive reviews and comments.</t> > </section> > </section> > </back> > > <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output > in > fixed-width font. In the txt output, there are no changes to the font, > and the quotation marks have been removed. > > Please review carefully and let us know if the output is acceptable or if any > updates are needed. > --> > > </rfc> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
