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
