[dns-operations] Announcement - DNS flag day on 2019-02-01

[Mark Andrews]

> On 31 May 2018, at 3:22 pm, Robert <robert at longwinters.org> wrote:
> 
> On Wed, May 30, 2018 at 6:22 PM, Paul Vixie <paul at redbarn.org> wrote:
>> we should probably not, ever, have put in any EDNS workarounds. let it fail
>> and start the shouting and finger pointing early. generally speaking, if AWS
>> customers see less web traffic, AWS will fix their DNS.
> 
> Isn't that what Michael's question is though? My reading of the flag
> day is it removes the work-arounds in resolver software for DNS
> systems which drop EDNS0 queries.  The DNS flag day website links to a
> tool which flags all EDNS faults with authoritative nameservers and
> specifically states: "must be green message All Ok". Is that actually
> true for the action being taken on 2019-02-01?
> 
> My reading of the website leads me to believe after the work-arounds
> are removed authoritative nameservers which respond to EDNS1 with
> anything other than BADVERS will still work just fine. I don't think
> the intention behind the statement "not seeing any clear customer
> benefit in fixing this in the next few months" is the same as "don’t
> have time to do this". The former statement, to me, is asking for a
> why when it appears there will be no impact for not correctly
> responding to EDNS1.
> 
> The why on this one seems to be "As a protocol designer and DNS
> resolver software maintainer, I would like to develop and implement
> EDNS1 which requires at present time DNS authorities respond to EDNS1
> queries with BADVERS". There's probably more to it than that, like why
> customers would want EDNS1 or what in general you're trying to
> accomplish (pro tip: referencing a case where you were able to live
> without it is not really a selling point). But I'm sure if there was a
> version 0 of something, we'd probably want a version 1 at some point,
> and it isn't really shocking behaviour to return an error when
> presented with a version you're not expecting (I'm thinking of how
> this works with HTTP versions).
> 
> Ultimately, I like new technology, DNS is spiffy, and I appreciate the
> work everyone does on moving our quirky Internet forward and needs and
> use cases change. Thanks (seriously, I'm not being glib). I do think
> efforts and messaging like this on the list does a disservice to the
> very initiatives you're trying to accomplish by conflating issues and
> making it look like you're trying to push forward an agenda which has
> no clear use case.
> 
> My suggestion is you clarify what the DNS flag day actually will
> impact and provide guidance on how to interpret the results of the
> validation tool to untangle the two issues: DNS systems which drop all
> EDNS queries, and BADVERS for EDNS1.

We introduced A6 and AAAA lookups for IPv6 and had to fight authoritative
servers to give valid NOERROR NODATA answers.  Every query is for a A record!

We introduced EDNS and had to fight authoritative servers to get a answer.
We expected FORMERR and handled that.

We introduced DNSSEC and had to fight authoritative servers to get a answer.
Some servers dropped queries with the DO bit set.

We introduced the AD bit in the query and we couldn’t trust AD in the response
because DNS servers blindly copied bits from the query.  We also had servers
that refused to respond to queries with the AD bit set in the query.

We introduced DNS COOKIES (EDNS option) and had to fight authoritative servers
to get valid answer or a answer at all.

None of the deployment of new features like this should have been a issue if
the servers WERE FOLLOWING THE PUBLISHED PROTOCOL!!!

If we send out test EDNS(1) ~50% of the servers in the world mishandle them in
some shape or form.

If we send out test queries with a EDNS option bit set around 10% of the servers
in the world will mishandle them.

The flag day will remove the workarounds for all queries up to and include
those with DNS COOKIES in them.

I don’t know when we will be sending EDNS(1) queries or queries with a EDNS
flag bit other than DO but we are all tired of having to work around the
garbage that is being deployed today.  The use of both of these extension
mechanisms has been proposed in the past.

I’m tempted to suggest that EDNS(100) queries with a currently unassigned EDNS
bit set and EDNS option 100 set be sent for 3 years to clean out all the broken
authoritative servers out there.  That way we take all the pain at once.

I’ve already suggested to some CC TLDs that they audit all the servers they
delegate to and remove the delegations that contain a provable broken server
after a grace window to get the server corrected.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org