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

[Brian Dickson]

To quote the late Douglas Adams, from HHGttG:
>
> “There’s no point in acting surprised about it. All the planning charts
> and demolition orders have been on display at your local planning
> department in Alpha Centauri for 50 of your Earth years, so you’ve had
> plenty of time to lodge any formal complaint and it’s far too late to start
> making a fuss about it now. … What do you mean you’ve never been to Alpha
> Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away,
> you know. I’m sorry, but if you can’t be bothered to take an interest in
> local affairs, that’s your own lookout. Energize the demolition beams.”


The main issue with having the discussion on github, is that it is a
discussion on github, not on a major mailing list involving the operators
and folks doing independent implementations.

The other main issue is, that EDNS UDP size is negotiated.
This means that it is NOT required that the default be the same on both the
client and server.
I would argue that which end should be lower, should depend largely on:

   1. The number of potential places overrides are necessary
   2. The comparative skill and expertise of the operators in those places
   3. The log-log nature of distribution of volume of queries between the
   top-talkers (biggest recursives and biggest authorities) and the long tail
   4. The position in the ecosystem of the various software elements, i.e.
   client-recursive vs recursive-root vs recursive-TLD vs recursive-leaf-auth

There is asymmetry involved, when a lot of small-ish clients have new
defaults that end up triggering excessive TCP traffic, which
disproportionately impacts the authority server operators who then have no
control over the situation.

As such, I would greatly prefer the recommendation be lifted to a higher
number, that is supported by the data, which achieves the following
simultaneous goals:

   - Minimize probability of fragmentation (to approximately 0.1% or 0.01%
   or even lower)
   - Minimize the resulting degree of TCP traffic triggered by DNS
   responses that exceed the UDP size negotiated

To me, that means maximizing the UDP size within a reasonable range of
observed data points with similar-enough behavior.

>From a theoretical perspective, I would be surprised if 1452 wouldn't work,
but the data suggests otherwise, from what I recall. (1452 = 1500 - 8 bytes
for MPLS or 802.1q, twice, plus L2 (ethernet frame) encapsulation over
MPLS, plus IP-in-IP encapsulation, either/or (twice).
If 1400 will work pretty much as well as 1232, I really want to encourage
re-evaluating consensus regarding the Flag Day 2020 number.

Brian

P.S. Maybe we could call this "frag day" instead? Apologies if anyone finds
that term offensive for any reason. But this is all about fragmentation,
and "frag" is much less of a mouthful, and it rhymes with "flag".

On Fri, Sep 11, 2020 at 9:46 AM Vladimír Čunát <vladimir.cunat+ietf at nic.cz>
wrote:

> On 9/11/20 4:44 PM, Paul Hoffman wrote:
> > If this is really just a vendor-driven flag day, please be clearer about
> that on the web page.
>
> The GitHub repo and other places have been open for *everyone* to
> participate in the discussions.  That's how I understand the "we",
> similarly to "we DNSOP".  Yes, the final number was not unanimous, but
> such a thing rarely happens.  And yes, I think it's true that
> open-source resolver vendors were the most active there.
>
> --Vladimir
>
> _______________________________________________
> 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/20200911/60da8f8f/attachment.html>