DNS Flag Day, Friday, Feb 1st, 2019

[dougb at dougbarton.us (Doug Barton)]

On 2019-01-31 08:32, James Stahr wrote:

> 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...

That understanding is flawed, but understandable given how deeply 
ingrained this misinformation has become in the zeitgeist. Sections 4.2 
and 4.2.2 of 1035 clearly state that TCP is an expected channel, not 
optional.

This is relevant operationally for two reasons. First while most folks 
make an effort to keep answers under 512 bytes for response time 
reasons, you cannot guarantee that someone, somewhere in your org won't 
add a record that overflows. Also, you are guaranteed to overflow at 
some point once you roll out DNSSEC. I've even seen seemingly mundane 
things like SRV records overflow 512 bytes.

The other reason it's relevant operationally is that there are more and 
more experimental projects in development now that involve using TCP, 
even without the need for truncation, as a way to have more assurance 
that a response is not spoofed. There are also efforts under way to 
evaluate whether "pipelining" DNS requests to servers that you are 
already sending a lot of requests to is ultimately more efficient than 
UDP at high volumes.

So, like lack of EDNS compliance, lack of TCP "compliance" here is going 
to be a limiting factor for the growth of new features, at minimum; and 
could result in actual breakage.

hope this helps,

Doug