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
