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 _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
