i'm replying to several messages here, all from francis dupont. > Francis Dupont <mailto:francis.dup...@fdupont.fr> > Tuesday, March 24, 2015 1:39 PM > ... > A 2mn timeout simply has no chance to scale.
i agree. it cannot scale. in addition, it's exceedingly easy to attack responders which implement [RFC 1035 4.2.2] by repeatedly connecting and doing nothing. however, for servers not at that moment under attack, the responders who implement the specification's two minute timeout is adequate for the limited volume of TCP traffic a server will see from clients who fail over to TCP after trying UDP. this means that while it's not ideal, it's not as broken as it could be. with changes to recommended initiator behaviour, we could make these existing servers more broken, or we could preserve their present level of brokenness, but we cannot make them less broken. i'm going to argue, below, for preserving their present level of brokenness. > > So I propose: > - make clear that TCP support is mandatory. > - allow servers to use the timeout they like, even a zero timeout > (the last point should be discussed). Note a zero timeout doesn't > mean "send the response and close" but "send the response, check > there is not pending query, and close". i am comfortable with this approach, but i would like to also specify (in one of the tcp related documents now circulating, or in a new one, that's a detail) that initiators SHOULD NOT remain connected and idle unless they are acting under some later specification under which idleness has been explicitly negotiated. obviously, any existing initiators will not obey the SHOULD NOT, but i would like to preserve the responders' present level of brokenness by not adding any new TCP connection idlers until and unless there is a protocol change by which a responder can signal its willingness to participate in an idle mesh. note that <http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01> is an example of a protocol revision by which idleness could be explicitly negotiated. i think a simpler approach could work, like adding one bit of the EDNS extended-flags mask to say "the sender of this message would be happy about remaining connected but idle". my reason for thinking this would be enough is, there's no way to reliably tune specific idle periods, and a TCP speaker who signals their willingness to remain idle must also be prepared to close least-recently-used connections when the pool of potential connections is running dry. > Francis Dupont <mailto:francis.dup...@fdupont.fr> > Tuesday, March 24, 2015 2:26 PM > In previous mail [Paul Wouters] wrote: > > >> If signaling for this is needed, then a separate document would be good. > => not needed but very useful: the idea is not to allow servers > to use short timeouts with clients which express they don't matter, > but to allow them with all clients. Note this is why it is a protocol > change... i believe that the last of the old-style initiators who treated premature closure by the responder as an urgent condition warranting a message to the console or the system log file have diminished to the level of noise, but that the change francis is asking for here, along with the clarification i'm asking for above as to non-idleness, along with a clarification to the effect that initiators SHOULD NOT treat premature closure by the responder as an urgent condition, reaches the level of "protocol change" not "clarification". > Francis Dupont <mailto:francis.dup...@fdupont.fr> > Tuesday, March 24, 2015 2:42 PM > In previous [Duane Wessels] wrote: > >> I believe 5966bis already addresses your first point quite clearly. >> (note: first point is to make TCP support mandatory) >> >> For example, it says: >> >> This document therefore updates the core DNS protocol specifications >> such that support for TCP is henceforth a REQUIRED part of a full DNS >> protocol implementation. > => but has this statement got a consensus? If it is the case > of course there is no reason to write twice the same thing. because of the installed base, i think we should say RECOMMENDED rather than REQUIRED. we cannot reasonably redefine existing working systems as unfit for duty. note, i do not know if we have consensus on this general approach, nor do i know whether the strength of that consensus would be higher for RECOMMENDED than for REQUIRED. however, i do know that i would lodge an objection if the REQUIRED form were to reach consensus. i realize that this language is already in RFC 5966 (August 2010), so, that document was a protocol change not a clarification. > >> Regarding your second point, Paul already pointed you to >> draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I >> think others felt it was unnecessarily complex. Here's what 5966bis says: >> >> DNS currently has no connection signaling mechanism. Clients and >> servers may close a connection at any time. Clients MUST be prepared >> to retry failed queries on broken connections. > => unfortunately this is a change in the protocol the document is > not supposed to do here even it both makes sense and follows the real > world situation. > since i know of stub resolvers (which i wrote and which saw wide distribution) which treat premature closure by the responder as an urgent condition, i believe that a recommendation that this not be done is now necessary, and i also believe that such a recommendation constitutes, as francis claims here, a protocol change. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
