DNS Flag Day, Friday, Feb 1st, 2019

Thu Jan 31 11:59:24 UTC 2019

On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean <
nanog at radu-adrian.feurdean.net wrote:

>
>
> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote:
> > You do realise that when the day was chosen it was just the date after
> > which new versions of name servers by the original group of Open Source
> > DNS developers would not have the work arounds incorporated?
>
> I think it's pretty safe to say that the "DNS Flag day" is more like a
> date of "end of support" rather than an "service termination". My guess is
> that some uncompliant servers will be still running long after that date...
>
> --
> R-A.F.
>

(resending from correct address)

Right.

The concern is that it's *also* the date when all the major recursive
lookup servers are changing their behaviour.

New software availability date?
Awesome, go for it.

Google, Cloudflare, Quad9 all changing their codebase/response behaviour on
a Friday before a major sporting and advertising event?

Not sounding like a really great idea from this side of the table.

Are we certain that the changes on the part of the big four recursive DNS
operators won't cause downstream issues?

As someone noted earlier, this mainly affects products from a specific
company, Microsoft, and L7 load balancers like A10s.  I'm going to hope
legal teams from each of the major recursive providers were consulted ahead
of time to vet the effort, and ensure there were no concerns about
collusion or anticompetitive practices, right?

I'm fine with rolling out software that stops supporting bad behaviour.

What I find to be concerning is when supposedly competing entities all band
together in a pact that largely holds the rest of the world hostage to
their arbitrary timeline.

Perhaps it's time to create a new recursive resolver service that
explicitly *is not* part of the cabal...

Matt
(hoping and praying this weekend will go smoothly)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190131/93d18509/attachment.html>