[dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01

Puneet Sood puneets at google.com
Fri Sep 11 15:47:18 UTC 2020


Google Public DNS posted a message on github about our plans:
https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183.

Background: Similar to what Ralf Weber said, over the last couple of
years we have seen issues with large domains related to UDP
fragmentation. It is not always obvious from the initial problem
report, which tends to be about a problem at the application level,
that the root cause is DNS UDP packet fragmentation. Setting lower
EDNS0 buffer size values solved the reported problems. Doing this more
widely for our resolver service will reduce operational overhead.

We plan to start setting a smaller EDNS0 buffer size (1400) starting
on October 1. Our experiments have shown that 1400 has minimal
difference from 1232. This will be a gradual rollout over 4-6 weeks.

-Puneet

On Fri, Sep 11, 2020 at 11:04 AM Ralf Weber <dns at fl1ger.de> wrote:
>
> Moin!
>
> On 11 Sep 2020, at 10:29, Viktor Dukhovni wrote:
>
> > Paul is not arguing against avoiding fragmentation, IIRC his name is on
> > a draft recommending fragmentation avoidance.  So I think the issue is
> > really about which numbers to go with.
> I think nobody is thinking that. We do have an agreement that fragmentation
> does not work and thus we must make sure to not send packets that will
> fragment. The whole discussion is about picking a default number.
>
> > While 1232 is in the ballpark, it may be too conservative, the case for
> > 1232 rather than perhaps say 1400 didn't look that compelling.  For most
> > users the larger number is also fine, and sometimes even avoids (notably
> > rare) problems where a larger value works, but the smaller does not.
> I recall an incident where an auth server was accepting a maximum size
> around 700 bytes, and we could not resolve it as at that time our default
> size was 4000. However some other resolver software could resolve as it
> was advertising an 512 byte EDNS0 buffer in those circumstances. These
> are the workaround we want to get rid of and as a vendor and operator of
> DNS resolver software. As an operator or vendor you will get calls/tickets
> when your software can not resolve something and other software can, and
> the consensus of the major resolver software vendors is to use 1232 as
> the default EDNS0 buffer size.
>
> Most if not all software still will have a switch where you can make it
> bigger or smaller. The only benefit of having a larger size is less
> switches to TCP and the impact of this is way smaller then the impact of
> DoH and DoT also coming to authoritative servers.
>
> So I still think 1232 is a good default number, and rather then fighting
> over a few bytes the DNS community should work on other stuff.
>
> So long
> -Ralf
> —--
> Ralf Weber
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations




More information about the dns-operations mailing list