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

[Viktor Dukhovni]

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.

-- 
    Viktor.