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

[Daniel Griggs]

Hi,

Just to add to that, I’ve been working with Azure recently and they warn
that any packets over 1400 bytes will be fragmented, which seems crazy, but
there it is.

IMHO It doesn’t seems unreasonable though to aim to support networks that
the majority use and to let broken networks be broken.

Daniel

On Tue, 21 Apr 2020 at 8:27 AM, Petr Špaček <petr.spacek at nic.cz> wrote:

> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
Sent from Mobile Command
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200421/eb5abd04/attachment.html>