[dns-operations] For darpa.mil, EDNS buffer == 1232 is *too small*. :-(

[Brian Somers]

On Apr 21, 2020, at 12:00 AM, Paul Vixie <paul at redbarn.org> wrote:
> 
> On Tuesday, 21 April 2020 06:20:04 UTC Petr Špaček wrote:
> 
>> As for OpenDNS experience - I'm hesistant to generalize. According to
>> https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/
>> 20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx DO bit is sent
>> out only since Sep'2018, and presumably from resolvers in data centers.
> 
> i understood the opendns team to say that they also used 1410 as the maximum 
> buffer size in responding to downstream queries. perhaps they can expand here.

We only restrict upstream advertised buffer sizes and only drop fragments
inbound, so our experience only covers resolver -> nameserver comms
where the resolver has no “funny stuff” such as conntrack, nat, VPNs etc
on the data path.

We advertise a bufsize of 4096 to the client in our EDNS responses and
will respond with payloads up to that size.  We expect the client to DTRT
WRT their requested bufsize based on their environment.

So for example, clients that wish to use DNSCrypt or query signed data
can go nuts with a large (4k) bufsize.  Clients get to (literally) keep all of
the pieces if they ask for (say) 1400 bytes, don’t block fragments and
have layers of local stuff that reduces the MRU to <1400.

I agree with Petr in that our experience is only 6 months old in terms
of asking questions that solicit larger DNSSEC responses, although our
prior experience is not to be sniffed at WRT >1410 = TC experiences.

WRT 1232, I don’t have enough experience to argue that it’s a good idea,
but (again, agreeing with Petr) just because 1410 is good for an ITW
resolver doesn’t mean it’s good for everyone.  I would (FWIW) err on
the side of caution and suggest conservative defaults in the hope that
someone running services ITW would also be qualified to choose
appropriate numbers.

—
Brian