[dns-operations] DNS flag day 2020: Recommended EDNS buffer size discussion

[Joelle Maslak]

I've used 1200 as well at a previous job with no issue for years (and it
was a big enough deployment if there were issues, they would have been
noticed).  I do not recommend sending fragmented IPv6 packets (as suggested
elsewhere on this thread), as too many people block fragments on IPv6.

I'm not commenting on whether or not this should be a flag day, just that I
have a lot of experience with 1200 at scale and it seems to work fine.  My
gut tells me 1220 would be fine too, I picked 1200 because I knew it was
safe even if I counted slightly wrong.  :)

On Mon, Sep 2, 2019 at 1:25 AM Florian Weimer <fweimer at redhat.com> wrote:

> * Jerry Lundström:
>
> > Hi all,
> >
> > I have opened an issue that will serve as a public, open to all,
> > discussion forum for what the recommended EDNS buffer size should be
> > for DNS Flag Day 2020.
> >
> >   <https://github.com/dns-violations/dnsflagday/issues/125>
> >
> >> Please note that the exact recommended EDNS buffer sizes have not been
> agreed upon, the current ballpark around 1200 (1220, 1232, …) is to limit
> the risk of fragmentation in IPv6.
> >
> > Note that most of the text on dnsflagday.net mentions 1220 bytes.
>
> I personally have used 1200 bytes, but I can switch to 1220 if that's
> the consensus.  Previously, the consensus was that fragments were good
> for the network (which I found rather odd).
>
> > Please feel free to voice your opinion!
>
> What about generating atomic fragments by default, to support stateless
> IPv6 UDP service?  Or not generating atomic fragments under any
> circumstances?  Would that be a separate discussion?
>
> Thanks,
> Florian
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190902/f13b478e/attachment.html>