[dns-operations] Geoff Huston on DNS-over-TCP-only study.

[Paul Vixie]

George Michaelson wrote:
> ...
> So, while I understand we're not DNS experts and we may well have made some mistakes, I think a one word 'canard' isn't helping.

there is no way to either get to or live in a world where dns usually
requires tcp. there would be way too much state. most people are capable
of writing the one-line perl script that will put a dns responder into
tcp exhaustion and keep it there at very little cost to the attacker,
but those same people can read section 5 of RFC 5966 and not see the
threat. granted that if all name servers miraculously implemented the
recommendation "servers MAY impose limits on the number of concurrent
TCP connections being handled for any particular client" then the perl
script would have to be longer than one line, there's just no world there.

had the original dns tcp protocol been structured so that the server
closes and the clients won't syslog anybody or otherwise freak out when
the server closes, we could imagine a high transaction rate on
short-lived connections. tcp's 3xRTT and 7-packet minimum would seem
harsh but at least we'd have some hope of goodput during deliberate
congestion attacks.

an experiment that looks at this from the client's point of view tells
us nothing about the server's availability during congestion. i could
wish that measurements of tcp dns performance would include a caveat
such as "this has not been tested at internet scale" or even
"internet-wide dependence on dns tcp may be vulnerable to trivial denial
of service attacks".

almost everybody who looks at this says "just use TCP". if the solution
to the bcp38 problem in DNS were that easy, we would not have written
<https://www.usenix.org/legacy/publications/login/2009-12/openpdfs/metzger.pdf>
and william would not have written RFC 6013.

it's also worth looking again to
<http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-02>.

vixie