DNS Flag Day, Friday, Feb 1st, 2019
Doug Barton
dougb at dougbarton.us
Thu Jan 31 20:29:26 UTC 2019
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
More information about the NANOG
mailing list