Hi folks, I've spent some time reading the various discussions around what bufsize should be requested and what we're trying to achieve by limiting that bufsize. I don't have anything productive to add in this regard, but I do have some practical experiences and numbers to share that will likely be of interest and may even be useful to many folks here.
Our (OpenDNS/Cisco) expectations & config: - Servers (nameservers or resolvers) do their best to reply as asked The client wants the data and can decide on what risk the chosen bufsize implies in their environment. Servers can apply practical limits to bufsize to avoid large buffers or huge amplifications etc. We (resolver) limit responses to bufsize=4096 - Clients (stubs or resolvers) solicit the bufsize It's up to them to decide, and the service they're talking to should generally honour the request as best they can. We (resolver) limit requests to 1280 <= bufsize <= 1410 The value used is pushed up from 1280 based on the client bufsize Our stubs will use large bufsize values (4096) if they have a trusted network path or are using DNSCrypt to secure the query & response. Our resolvers don't set DF in queries - but maybe we should? I think that's likely a problem for PMTUD. - Network operators drop fragments We configure all of our resolver machines to drop inbound fragments. We allow outbound fragments (that's the client's problem!). Inter-resolver traffic uses bufsize=4096 and is encrypted/authenticated using DNSCrypt. This intersite traffic is allowed to pass fragments at the firewall. To date, I have only seen ONE SINGLE occurance of an issue due to this configuration and that was because the upstream NS responded with data sizes that ignored bufsize altogether (so their responses were sometimes fragmented and dropped). What does this tell me about the data path between our resolvers and the nameservers of the world? - Routing equipment that fragments data to small sizes does not seem to exist on this data path. - IPv6 PMTU based fragmentation doesn't happen for payloads of 1410 or less. - Our heuristic of 1500 - 60 - 8 - (fudge=22) works in practice! This doesn't tell us anything about the limitations of the client to resolver path, so there may be real world issues there, but I don't think anybody here is trying to limit that end in any way. -- Brian _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
