Re: DNS Flag Day, Friday, Feb 1st, 2019

[James Stahr <stahr () mailbag com>]

On 2019-01-31 08:15, Mark Andrews wrote:

> We actually have a hard time finding zones where all the servers are
> broken enough to not work with servers that don’t fallback to plain
> DNS on timeout.  We can find zones where some of the servers are like
> that, but there is usually one or more servers that do respond
> correctly.
>
> Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones
> will have problems with updated servers.

I think the advertised testing tool may be flawed as blocking TCP/53 is 
enough to receive a STOP from the dnsflagday web site.  It's been my 
(possibly flawed) understanding that TCP/53 is an option for clients but 
primarily it is a mechanism for the *server* to request the client 
communicate using TCP/53 instead - this could be due to UDP response 
size, anti-spoofing controls, etc...

So is the tool right in saying that TCP/53 is a absolute requirement of 
ENDS0 support for "DNS Flag Day"?  If so, do we expect a dramatic 
increases in TCP/53 requests over UDP/53 queries?  Or is the tool flawed 
in its' claim that the DNS Flag Day changes *require* TCP/53 in order to 
resolve ones domain?  Based upon my reading, the big concern is a 
edns=timeout result (from the ISC tool) not a edns512tcp=timeout.


While I applaud the effort, the message and delivery could have been 
better. My first read on DNS Flag Day was that this was going to be the 
day new software versions were to be released which deprecated EDNS0 
fallback measures so the adoption would be a gradual process by updating 
the latest versions of several DNS servers, only to find out that many 
resolvers used by end users use will be upgrading on Feb 1rst.  Now, it 
sounds like the rollout schedule is on their timetable and could happen 
over the next several weeks and months.  So really not a Flag "Day" now 
is it? I guess that's also why the date being on a Friday also isn't 
really a concern...

Finally, why has no one stepped up to setup an updated resolver prior to 
Feb 1rst for actual testing? Or are there instructions on how one could 
setup their own resolver setup prior to Feb 1rst?  No offense, but I'm 
not jumping to a brand new train of code just to enforce DNS Flag Day 
but I might choose enforce now under *existing* code bases rather than 
waiting for everyone else using Cloudflare/Google/OpenDNS as resolver 
may see me after Feb 1rst?   If anyone has such instructions, post them 
- or put them on dnsflagday.net for anyone else wanting to adopt/test.  
Just some thoughts...


--
-James