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

[Brian Dickson]

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

> On 9/11/20 9:14 PM, Randy Bush wrote:
> >> 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.
> > for cabals which like a bubble, this is a feature, not a bug
>
> Are you telling me that Flag Day 2020 got too little publicity in here
> and similar circles?  (its web, linked to GitHub, the plans, etc.)  I
> rather thought we've pushed it everywhere often enough to make anyone
> sick of the topic, but perhaps my perception is biased.  I'm really
> sorry if anyone feels excluded from the discussion.  To be clear, we've
> had multiple "Flag Day 2020" threads just on this list.
>

TL;DR: Yes, or rather the content of that discussion was not necessarily
raised adequately in other venues, IMNSHO.

The main participants on that github site appear to not have had enough
breadth and depth of experience on networks, low-level transports, and all
the roles in the DNS ecosystem, to collectively make supportable
conclusions/decisions.
E.g. "voting" based on participant's opinions is neither justifiable nor
sensible, especially if there are only five voters. The majority of those
votes appeared to be suffering from "group think" after reading the paper
discussing the range of 12xx to 1400.

In particular, things really went off the rails when discussing using
client-side defaults lower than current defaults, i.e. Paul Vixie's
suggestion to leave the offered client bufsize as is, and only change the
server-side configured max size.

The discussion around that mostly devolved to vendors/implementers
defending past engineering/implementation choices (that's how we did it),
without adequately considering the actual real-world impact.

The deployment to client side machines will be a slow roll, for sure.

But the difficulty, time, and pain, to roll that *back* when it is
discovered as a major operational PITA and cost for authority operators,
has been completely overlooked.

In short: I would be perfectly okay if the recommendation were ONLY for the
authority (and server side of resolvers) to lower their default configured
UDP bufsizes, at which point having a range of recommended values (rather
than a single value) would be more appropriate.
Server-side defaults can have their values changed (overridden) by config
changes, but that ONLY has effect if the clients are NOT ALSO implementing
the SAME values.

That's the problem: EDNS0 UDP Bufsize negotiation allows different values
to be configured/offered, and uses the MINIMUM value. If both ends have
their defaults lowered, and that causes a problem, it CANNOT be fixed
unilaterally.

Even only considering the recursive resolver population (estimated at ~3M),
this is a huge issue, and IMHO a huge mistake.

The analysis of the relative impact (e.g. N x cost for TCP) ignores things
like state exhaustion, where the state CANNOT be increased (since port 53
is mandated, and server IP addresses are hardcoded everywhere). You cannot
add IP addresses or ports to fix state exhaustion, which can be a localized
issue on anycast operated networks.

Sorry for the long message, but it is really a big deal, and the timeline
is unfortunate. I'd suggest pushing the date back by a month or two
minimum, and re-opening discussion on these issues on the github site.

Or, discuss them here with a wider set of participants.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200911/d42b9a54/attachment.html>