On Thu, Sep 22, 2022 at 2:05 AM Kazunori Fujiwara <[email protected]> wrote:
> > From: Petr Špaček <[email protected]> > >> Then, do you agree the following requirements ? (as DNS software > >> developpers) > >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4, > >> and SHOULD not use FRAGMENT header on IPv6. > > > > Theoretically yes, but it might not be achievable depending on OS > > API. We tried many iterations in BIND, and discovered that APIs (at > > least in Linux) are horrible and there are traps everywhere. > > Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and > they often don't work as expected. > [...] > On IPv4, I would like to write it in such a way that "setting the DF > bit" is an goal, and that OS implementors and DNS server > software developpers will do their best. > We (GoDaddy) have actually had some very recent experience with real-world situations, and have some results to share. The TL;DR: of those is: it may not be a good idea to set the DF bit on UDP if the intention is to improve reliability while avoiding fragmentation, and interface MTU may need to be set lower. Here is what we have observed: - IF the client and server BOTH have settings (EDNS bufsize and server-side UDP max size configuration) that are larger than the real-world path MTU end-to-end - AND UDP responses have DF=1 set - AND UDP responses with TC=1 still exceed the minimum path MTU - THEN: - Packet-too-big ICMP messages are sent, that are useless/ignored or even blocked/dropped by ACLs - These over-MTU UDP packets are dropped (because DF=1) - The TC=1 response is never received - Result: - Depending on the DNS software implementation, fallback to smaller size UDP or to TCP may not occur - Additionally, TCP itself may need to be an in-scope issue for recommendations (not sure if it is), specifically because: - IF the CLIENT has its configured MSS larger than the smallest MTU on the path to the server - MSS normally defaults to interface MTU - AND the client, server, or path do not enable/support PTMUD (e.g. blocking of ICMP packet too big messages, or NAT issues) - AND the SERVER sets DF=1 - AND the first data packet in the response exceeds the actual path MTU - THEN: - TCP will not work (the first packet will never reach the client) The recommendations might end up being much simpler, as a result. The only successful approach we have found is to address both the UDP and TCP issues. The easiest way to do both of these is to set the server MTU to a lower value (i.e. whatever value makes sense, based on observed traffic). And for clients, if the client is aware of a commonly-used network path with lower MTU, set the client's interface MTU to that value, as well as configure the EDNS bufsize to that same value (or lower). It may be the case that DNS software cannot unilaterally achieve these things, and it may be necessary to check whether those conditions are met. How the DNS software behaves if the conditions are not met is likely a question to answer: - Is it better to prevent the software from running (give a fatal error), or to give a warning (that might be ignored) and run anyway? - How can the condition itself be checked (interface MTU vs path MTU vs EDNS bufsize)? Brian
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
