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

Petr Špaček petr.spacek at nic.cz
Tue Apr 21 06:20:04 UTC 2020

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
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

More information about the dns-operations mailing list