[dns-operations] DNS flag day 2020: The OpenDNS/Cisco perspective

[Brian Somers]

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