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

[Petr Špaček]

On 20. 04. 20 22:22, Viktor Dukhovni wrote:
> On Mon, Apr 20, 2020 at 12:52:49PM -0700, Brian Somers wrote:
> 
>> On Apr 18, 2020, at 9:39 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>> Is there any new information on whether something closer to 1400 is
>>> generally safe also for IPv6?
>>
>> At Cisco we allow up to 1410 bytes upstream and drop fragments.  We prefer IPv6
>> addresses when talking to authorities.  We’ve been doing this for years (except for
>> a period between Feb 2019 and Aug 2019).  Zero customer complaints.
> 
> So perhaps the advice to default to 1232 should be revised:
> 
>     https://dnsflagday.net/2020/#dns-flag-day-2020
> 
> I see some movement in that direction, with the recommendation of 1220
> in:
> 
>     https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00#section-3
> 
>        o  Full-service resolvers SHOULD set EDNS0 requestor's UDP payload
>           size to 1220.  (defined in [RFC4035] as minimum payload size)
> 
>        o  Authoritative servers and full-service resolvers SHOULD choose
>           EDNS0 responder's maximum payload size to 1220 (defined in
>           [RFC4035] as minimum payload size)
> 
> revised in -01/-02 to:
> 
>     https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-02#section-4
> 
>        o  [RFC4035] defines that "A security-aware name server MUST support
>           the EDNS0 message size extension, MUST support a message size of
>           at least 1220 octets".  Then, the smallest number of the maximum
>           DNS/UDP payload size is 1220.
> 
>        o  However, in practice, the smallest MTU witnessed in the
>           operational DNS community is 1500 octets.  The estimated size of a
>           DNS message's UDP headers, IP headers, IP options, and one or more
>           set of tunnel, IP-in-IP, VLAN, and virtual circuit headers, SHOULD
>           be 100 octets.  Then, the maximum DNS/UDP payload size may be
>           1400.
> 
> While darpa.mil still need to enable TCP, a more generous buffer size
> that avoids IPv6 issues will also avoid unnecessary and potentially even
> unavailable TCP fallback.  So I'm in favour of 1400 or 1410 (do we need
> more empirical evidence from other vantage points?) assuming those are
> also safe.
> 
> If the IPv6 obstacles are typically closer to the resolver than the
> authoritative server, just Cisco's experience may not be enough to make
> a definite conclusion.

Please let's not jump to conclusions, especially because of single anecdote.

As Knot Resolver developer I counter with another anecdote:
We have experience with networks where ~ 1300 buffer was workable minimum and 1400 was already too much.

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. 

Results would be very different for recursive resolver deployment deep in corporate networks/on the last mile.

DNS-over-TCP is mandatory to implement so please let's stop working it around.

-- 
Petr Špaček  @  CZ.NIC