Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
I am indifferent about what label we stick on this, but perhaps the document should have a section on implementations? However, I do feel that the Security Considerations is missing on the risks of dropping packets, ICMP filtering and dangers of PMTUD. Also it feels weird to me that the IP_PMTUDISC_OMIT is used by: BIND 9, NSD, Unbound, Knot DNS and PowerDNS, but neither the fact nor the reasoning behind the option is ever mentioned here. Hence, I think the Implementors section should be added to the document. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 20. 1. 2023, at 16:20, Paul Hoffman wrote: > > Given the long list of things in this document that ISC has thought about > and actively decided not to do, is it a good idea that we call it a "best > current practice"? > > --Paul Hoffman > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
On 20.01.2023 12:49, Ondřej Surý wrote: • UDP responders SHOULD limit response size when UDP responders are located on small MTU (<1500) networks. I don't know what this means. And how is this related to the previous recommendation to limit the response size under "1400". Hi, I think this means that if the server is on a network that has a MTU that is smaller than 1500 the response of the server needs to be limited to even less then 1400. This happens with e.g. PPoE DSL, where it is 1492 and if a VPN is used it is lower by 20-bytes (IP-in-IP), 50-bytes (IPv4 VXLAN), 70-bytes (IPv6 VXLAN), 60-bytes (IPv4 WireGuard) and 80 bytes (IPv6 WireGuard). Sincerely, Klaus Frank smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
On Fri Jan 20, 2023 at 6:53 PM UTC, Paul Wouters wrote: > It seems there should be more discussion which hopefully would lead to > a converging BCP before moving forward. Hearing from other main > implementations would be extremely helpful here. i have always been a fan of ISC's work, but i agree with two implications of the above observation. first, as stated, we should hear from more than one dominant implementations. second, unstated above but implied, the priorities of an implementer are sometimes time-variant (the implementer may think differently later) and often narrow (having more to do with the problems that implementer sees than with what the community can foresee.) long before the heat death of the universe, packets must grow in order to amortize header processing costs against larger payloads. yet fragmentation must not return. we ought to pave a step or two down the path that EDNS incorrectly precluded us from in its earliest and most ignorant form. so, i appear to be +1 to mr. wouters' suggestion above, for those reasons. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
On Fri, 20 Jan 2023, Paul Hoffman wrote: Given the long list of things in this document that ISC has thought about and actively decided not to do, is it a good idea that we call it a "best current practice"? It seems there should be more discussion which hopefully would lead to a converging BCP before moving forward. Hearing from other main implementations would be extremely helpful here. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of draft-ietf-dnsop-rfc8499bis
Thank you Paul and Kazunori. The chairs agree that both drafts (glue-is-not-optional and rfc8499bis) should go to WG Last Call together. We will coordinate this further with the authors of both documents to move forward with the WGLC. Best, -- Suzanne, Tim and Benno On 20/01/2023 16:34, Paul Hoffman wrote: Greetings again. Kazunori and I have just submitted -05 of this draft to incorporate the consensus from the WG on how to talk about the types of glue. Please see the diff for the specific wording that was used to reflect the WG consensus. Note that we now normatively reference draft-ietf-dnsop-glue-is-not-optional because that draft explains what to do with the definitions in this draft. (I have no idea why there are those "skipping" sections; I'll report the bug.) This is now ready for WG Last Call. The chairs should move draft-ietf-dnsop-glue-is-not-optional and draft-ietf-dnsop-rfc8499bis to WG Last Call together. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
> On 20 Jan 2023, at 15:20, Paul Hoffman wrote: > > Given the long list of things in this document that ISC has thought about and > actively decided not to do, is it a good idea that we call it a "best current > practice"? Maybe. Though a BCP should go beyond documenting what BIND9 does. In many cases, what BIND9 does is the de facto BCP. However IMO a “real” BCP should include insights from other implementations and from operators. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Status of draft-ietf-dnsop-rfc8499bis
Greetings again. Kazunori and I have just submitted -05 of this draft to incorporate the consensus from the WG on how to talk about the types of glue. Please see the diff for the specific wording that was used to reflect the WG consensus. Note that we now normatively reference draft-ietf-dnsop-glue-is-not-optional because that draft explains what to do with the definitions in this draft. (I have no idea why there are those "skipping" sections; I'll report the bug.) This is now ready for WG Last Call. The chairs should move draft-ietf-dnsop-glue-is-not-optional and draft-ietf-dnsop-rfc8499bis to WG Last Call together. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-rfc8499bis-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Terminology Authors : Paul Hoffman Kazunori Fujiwara Filename: draft-ietf-dnsop-rfc8499bis-05.txt Pages : 56 Date: 2023-01-20 Abstract: The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 8499 and updates RFC 2308. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc8499bis-05 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8499bis-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
Given the long list of things in this document that ISC has thought about and actively decided not to do, is it a good idea that we call it a "best current practice"? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: BIND 9
Dear WG and authors, here's an status of UDP fragmentation mitigations in BIND 9 as of now. > 3.1. Recommendations for UDP responders > • UDP responders SHOULD send DNS responses without "Fragment header" > [RFC8200] on IPv6. > • UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) bit" > [RFC0791] on IPv4. We don't do that and we don't ever plan to implement this. BIND 9 sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT[a] with fallback to IP_PMTUDISC_DONT on Linux. On systems with IP_DONTFRAG (FreeBSD), we disable IP_DONTFRAG. (See my remark about PMTUD below...) > • UDP responders SHOULD compose response packets that fit in both the > offered requestor's maximum UDP payload size [RFC6891], the interface MTU, > and the RECOMMENDED maximum DNS/UDP payload size 1400.¶ The default EDNS0 buffer size is 1232, we don't allow sizes smaller than 512 and larger than 4096. We honour the requestor's size up to the configured limit (`max-udp-size`). > • If the UDP responder detects an immediate error that the UDP packet > cannot be sent beyond the path MTU size (EMSGSIZE), the UDP responder MAY > recreate response packets fit in path MTU size, or TC bit set.¶ If the send fails with EMSGSIZE, we set the TC and try to send minimal answer again. > • UDP responders SHOULD limit response size when UDP responders are > located on small MTU (<1500) networks. I don't know what this means. And how is this related to the previous recommendation to limit the response size under "1400". > 3.2. Recommendations for UDP requestors > • UDP requestors SHOULD limit the requestor's maximum UDP payload size to > the RECOMMENDED size of 1400 or smaller size.¶ The default is 1232 (`edns-buf-size`) > • UDP requestors MAY drop fragmented DNS/UDP responses without IP > reassembly to avoid cache poisoning attacks.¶ We don't do that and we don't plan to do that. > • DNS responses may be dropped by IP fragmentation. Upon a timeout, to > avoid name resolution fails, UDP requestors MAY retry using TCP or UDP with a > smaller requestor's maximum UDP payload size per local policy.¶ The fallback to TCP has been already implemented (after two UDP timeouts) > When avoiding fragmentation, a DNS/UDP requestor behind a small-MTU network > may experience UDP timeouts which would reduce performance and which may lead > to TCP fallback. This would indicate prior reliance upon IP fragmentation, > which is universally 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. I kind of feel this misses the other side - if there's a UDP timeout (for any reason), it also increases the attack window for poisoning the requestor's cache. Thus if a UDP response is dropped along the way because it's too big, it does come with a cost. The document and the security consideration also completely avoids the fact that accepting PMTUD for UDP is also considered harmful and dangerous -> which resulted in IP_PMTUDISC_OMIT in the Linux kernel (and similar technique in FreeBSD AFAIK). Notes: a. The option is available since Linux 3.15 - released in 2014, so it should be available virtually everywhere except some really old stuff. Even RHEL/CentOS 7 has backported this to their 3.10 kernel. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
