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
