[dns-operations] DNS flag day 2020: The OpenDNS/Cisco perspective
bsomers at opendns.com
Wed Feb 26 22:51:00 UTC 2020
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
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
- 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.
More information about the dns-operations