Dear Kazunori, We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/authors/rfc9715-diff.html).
We now have all of the necessary approvals and will move this document forward in the publication process. Thank you to all for your time! Best regards, RFC Editor/kc > On Jan 23, 2025, at 12:31 AM, Kazunori Fujiwara <fujiw...@jprs.co.jp> wrote: > > Dear RFC Editor, > > This revision is OK for me. > Please proceed. > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > >> From: Karen Moore <kmo...@staff.rfc-editor.org> >> Dear Paul, >> >> Thank you for your reply. We believe that this signifies your approval of >> the document, so we have marked your approval on the AUTH48 status page >> (https://www.rfc-editor.org/auth48/rfc9715). If that is not correct and you >> need more time for review, please let us know. >> >> We now await approval from Kazunori prior to moving forward with the >> publication process. >> >> Best regards, >> RFC Editor/kc >> >>> On Jan 22, 2025, at 12:21 PM, p...@redbarn.org wrote: >>> >>> Nothing from me. >>> >>> Sent from Workspace ONE Boxer >>> >>> On Jan 22, 2025 11:01, Karen Moore <kmo...@staff.rfc-editor.org> wrote: >>> Hi Warren, >>> >>> Thank you for your quick reply. We have noted your approval on the AUTH48 >>> status page for this document (https://www.rfc-editor.org/auth48/rfc9715). >>> >>> We now await approvals (or further updates if needed) from Kazunori and >>> Paul. >>> >>> Best regards, >>> RFC Editor/kc >>> >>>> On Jan 22, 2025, at 10:40 AM, Warren Kumari <war...@kumari.net> wrote: >>>> >>>> On Tue, Jan 21, 2025 at 6:05 PM, Karen Moore <kmo...@staff.rfc-editor.org> >>>> wrote: >>>> 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. >>>> >>>> Yes, thank you, I approve. >>>> >>>> W >>>> >>>> >>>> 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
