TL;DR: i'd like to only behave differently if the other side signals its readiness for it. in a "big TCP" model where thousands or tens of thousands of sessions remain open while idle (even if only for a few seconds), we are asking for application, library, kernel, RAM, CPU, and firewall conditions that are not pervasive in the installed base -- which includes tens of millions of responders who will never be upgraded, and whose operators are not reading this mailing list, and will not be reading any new RFCs on the topic.
if we want better TCP/53 behaviour than that required in RFC 1035 4.2.2, then we should define signalling that requests it, and we should behave differently if that request is granted. that's what "first, do no harm" means in an installed base that's literally the size and shape of The Internet. longer version: > John Heidemann <mailto:[email protected]> > Sunday, January 25, 2015 9:10 PM > ... > > We are, I think, in the lucky place of having a new feature (multiple > DNS queries over TCP with pipelining and reordering) with SOME level of > responder support and basically zero initiator use. > Do we really need new signaling? yes, i think so. you're only talking about old-style initiators here. there are problems on the responder side that i worry more about, because of the impact that new-style initiators could indirectly but pervasively have on old-style initiators, due to the behaviour of old-style responders. > ... The other question is harm on the > responder side. That's why I was trying to get to the bottom of the > assertion that DNS-over-TCP is inherently a DoS. there may not be a bottom. existing responders who follow RFC 1035 4.2.2 are extremely weak, but are in the critical path for existing initiators responding to TC=1 (or, in other cases where a UDP response is unusable or untrustworthy, which i'm loathe to describe in public.) if a new-style initiator prefers TCP and keeps a connection open longer than the time it takes to send just the queries it has in hand, and if the responder is old-style, then it causes significant problems for old-style initiators. denying service to a by-the-book RFC 1035 4.2.2 TCP responder is childs play. we must not do it on purpose. > I haven't seen > evidence supporting that claim, i am out of ideas as to what that might require. > ... and I think we can all recognize the > installed base of HTTP to show that at least someone can make TCP work > at scale on the server side. i have not, and i don't think anyone else has either, said that TCP cannot be made to work at scale. however, TCP/53 as described in RFC 1035 4.2.2 is not part of making DNS-over-TCP work at scale; quite the opposite. > > >>> bind >>> responders, since 4.8, has accepted pipelining, but with ordered >>> responses until a currently unreleased patch was put in recently. bind >>> responders through bind 8 did not read the next (potentially pipelined) >>> request out of the tcp socket until after it had sent its response to >>> the previous request, so, there was no parallelism of any resulting >>> cache miss activities. > > Most implementations whose TCP we've examined (bind 9.9 and unbound) > have performance problems when running over TCP. But performance > problems can be fixed incrementally and in place, unlike correctness > issues where people fail. the problems we must avoid involve servers whose source code you can't get access to. > > Yes, there are definitely performance problems that will need to be > fixed. But performance has very different deployment issues > than correctness does. the problems we must avoid involve servers who will never be upgraded. > ... > > I haven't seen anyone assert that TCP should become *manditory* for > future DNS. If it's encouraged, or at least not discouraged, then I > suggest we can abide a multi-year rollout. the problems we must avoid include those operated by people who do not read this mailing list, or new RFC's. -- Paul Vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
