> Ray Bellis <mailto:ray.bel...@nominet.org.uk> > Wednesday, March 25, 2015 8:05 AM > On 25 Mar 2015, at 09:52, Paul Vixie <p...@redbarn.org> wrote: > >> well then it bears further discussion, because to me it's certainly a >> change. there is no guidance in RFC 1035 as to whether an initiator should >> treat premature closure by the responder as a signal to try the same server >> again or move to the next server > > That sounds like a potentially useful addition to 5966bis - moving on to the > next server would seem to me to be the preferred reaction.
are you sure? because if a server is going to close connections prematurely, it may do so based on instantaneous load spikes, such as the number of active connections reaching 80% of quota, where the premature closure is designed to avoid connection overload rather than signalling actual connection overload. if in the UDP case we would respond to an unanswered query by repeating the same query to the same server, then in the TCP case we might want to do likewise. it could also be that the traditional UDP retry mechanism is seriously flawed, and that even in that case we should move on to the next server, and only return to the timed-out server if all other servers also time out. this bears discussion. > >> and, there is no guidance as to whether premature closure is an urgent >> operational matter deserving notification to the user's console or system >> logs. > > IMHO, any client that ever did this is over-reacting and I don’t believe > specific guidance is required. if 100% of the installed base had not at one time in the history of DNS behaved that way, i could agree. but because the specification's guidance is demonstrably light in this area, is there any harm in extending that guidance -- "for the avoidance of confusion or doubt" ? > > >> but since we must also guide the initiator to not leave a tcp session idle, > > We must? perhaps you've got me procmailed. see below: > From: Paul Vixie <p...@redbarn.org> > Date: Saturday, February 28, 2015 10:04 AM > To: Stephane Bortzmeyer <bortzme...@nic.fr> > CC: dnsop@ietf.org > Subject: [DNSOP] [TCP] edns-tcp-keepalive, and 5966bis > > > > ... please do not change recommended initiator behaviour in ways that > violate reasonable assumptions of current responders. if the client > wants to keep a connection open longer than it takes to send and > receive the queries they have on-hand, they should find out whether > the server agrees with this incompatible change to the connection > management logic described in RFC 1035 4.2.2. see also: > From: Paul Vixie <p...@redbarn.org> > Date: Thursday, March 19, 2015 4:27 AM > To: Andrew Sullivan <a...@anvilwalrusden.com> > CC: dnsop@ietf.org > Subject: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01 > > > Andrew Sullivan wrote: >> On Thu, Mar 19, 2015 at 03:58:47AM -0700, Paul Vixie wrote: >>> > >>> > if you want new behaviour, negotiate for it. >> So you want a way to signal the new behaviour and negotiate that? > > i don't care whether there's new behaviour. but if new behaviour is > going to be incompatible with existing implementations, then that new > behaviour must be negotiated. that's how we rebuilt this airplane in > flight over and over again from 1986 to the present. it's all "DNS". see also: > From: Paul Vixie <p...@redbarn.org> > Date: Wednesday, March 18, 2015 1:59 AM > To: dnsop@ietf.org > Subject: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01 > i have read draft-ietf-dnsop-5966bis-01, and i have some comments. > > tl;dr: this document is nowhere near ready to ship. > >> ... >> >> 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. > > this language is too strong, and breaks working configurations. many > DNS servers are completely functional for all intents and purposes > even though an upstream firewall or other middlebox prevents them > from hearing TCP requests. > > i suggest some adjective other than REQUIRED here. perhaps STRONGLY RECOMMENDED. ... >> Whilst this document makes no specific requirements for operators of >> DNS servers to meet, > > if that's true, then you really can't say REQUIRED (see above). > >> ... >> >> However, transport of UDP packets that exceed the size of the path >> MTU causes IP packet fragmentation, which has been found to be >> unreliable in some circumstances. > > can i ask, as the RFC 2671 author, that you change the word "some" to be instead the word "many" ? > >> 6. Connection Handling >> >> One perceived disadvantage to DNS over TCP is the added connection >> setup latency, generally equal to one RTT. To amortize connection >> setup costs, both clients and servers SHOULD support connection reuse >> by sending multiple queries and responses over a single TCP >> connection. >> >> DNS currently has no connection signaling mechanism. Clients and >> servers may close a connection at any time. > > this is factually wrong. servers are not permitted to close a > connection at any time. (this is what the spec says, and the > expectations of any implementation that faithfully followed the spec > must be called "reasonable"). > >> Clients MUST be prepared >> to retry failed queries on broken connections. > > this is factually wrong. a client can give up on a server for at > least the duration of the current transaction if it closes a > connection prematurely. > >> Section 4.2.2 of [RFC1035] says: >> >> If the server needs to close a dormant connection to reclaim >> resources, it should wait until the connection has been idle for a >> period on the order of two minutes. In particular, the server >> should allow the SOA and AXFR request sequence (which begins a >> refresh operation) to be made on a single connection. Since the >> server would be unable to answer queries anyway, a unilateral >> close or reset may be used instead of a graceful close. >> >> Other more modern protocols (e.g., HTTP/1.1 [RFC7230]) have support >> for persistent TCP connections and operational experience has shown >> that long timeouts can easily cause resource exhaustion and poor >> response under heavy load. Intentionally opening many connections >> and leaving them dormant can trivially create a "denial-of-service" >> attack. > > noting: this is why i frequently refer to the RFC 1035 connection management logic as "unfortunate". > >> It is therefore RECOMMENDED that the default application-level idle >> period should be of the order of seconds, but no particular value is >> specified. In practice, the idle period may vary dynamically, and >> servers MAY allow dormant connections to remain open for longer >> periods as resources permit. > > noting, as a recommendation, this is harmless to the installed base, > as long as the installed base remembers that a faithful > implementation of RFC 1035 4.[2].2 will not be doing this, and avoids > perturbing those servers with long-lived TCP sessions that their > connection management logic is ill-equipped to handle. > >> To mitigate the risk of unintentional server overload, DNS clients >> MUST take care to minimize the number of concurrent TCP connections >> made to any individual server. > > not just concurrent, but also, idle. no idle connections can be > permitted unless the client knows absolutely that the server is > modern and is following the specification now being reviewed. > >> ... >> For reasons of efficiency, implementations SHOULD wherever possible >> attempt to coalesce the two byte length field and subsequent DNS >> payload data into a single packet. > > i think you can word this more strongly. as in: "Since TCP responders > are sensitive to timeout conditions, some extant implementations will > abort a TCP session if the first TCP window does not contain both the > two-octet length field and the entire request message described by > that length field. TCP initiators should therefore take care to > transmit the two-octet length field, and the message described by > that length field, in a single TCP window." ... >> 7. Query Pipelining >> >> Due to the use of TCP primarily for zone transfer and truncated >> responses, no existing RFC discusses the idea of pipelining DNS >> queries over a TCP connection. >> >> In order to achieve performance on par with UDP DNS clients SHOULD >> pipeline their queries. When a DNS client sends multiple queries to >> a server, it should not wait for an outstanding reply before sending >> the next query. Clients should treat TCP and UDP equivalently when >> considering the time at which to send a particular query. > > add: "TCP initiators should be aware that some responders will answer > in order no matter what, and they should not therefore expect > parallelism. If performance is a consideration, the use of UDP will > be a better guarantor of same, unless the initiator is sure that the > responder is acting according to this amendment to the DNS > protocol." > >> DNS servers (especially recursive) SHOULD expect to receive pipelined >> queries. The server should process TCP queries in parallel, just as >> it would for UDP. The handling of responses to pipelined queries is >> covered in the following section. >> >> When pipelining queries over TCP it is very easy to send more DNS >> queries than there are DNS Message ID's. Implementations MUST take >> care to check their list of outstanding DNS Message ID's before >> sending a new query over an existing TCP connection. This is >> especially important if the server could be performing out-of-order >> processing. > > i think you mean "since" rather than "if", as in, "since the server > could be performing out-of-order processing." that is, if an > initiator is sure that the responder is answering in order, as most > TCP responders do today, then the initiator would be free to re-use > the same TXID over and over, as some TCP initiators are known to do > today. > >> In addition, when sending multiple queries over TCP it >> is very easy for a name server to overwhelm its own network >> interface. Implementations MUST take care to manage buffer sizes or >> to throttle writes to the network interface. > > i cannot imagine what this could mean, in real terms, to a resolver > implementer, having only UNIX or Windows system calls to work with. > can you provide some examples? > >> 8. Response Reordering >> >> RFC 1035 is ambiguous on the question of whether TCP responses may be >> reordered -- the only relevant text is in Section 4.2.1, which >> relates to UDP: >> >> Queries or their responses may be reordered by the network, or by >> processing in name servers, so resolvers should not depend on them >> being returned in order. >> >> For the avoidance of future doubt, this requirement is clarified. > > you can't do that. let me explain: > >> Authoritative servers and recursive resolvers are RECOMMENDED to >> support the sending of responses in parallel and/or out-of-order, >> regardless of the transport protocol in use. > > this works as a recommendation for responders, which initiators had > better be prepared to cope with, since the only time they have to > cope with it is if they use pipelining. > >> Stub and recursive >> resolvers MUST be able to process responses that arrive in a >> different order to that in which the requests were sent, regardless >> of the transport protocol in use. > > this does not work as a MUST, because existing implementations which > were faithful to RFC 1035 might not be able to do this -- and you > know this or you would not be trying to clarify the point at this > late date. i think that if you want new behaviour you have to > negotiate for it, not merely mandate it, since to mandate it would > invalidate previously-valid implementations and break > previously-working configurations. > >> ... >> 9. TCP Fast Open >> >> This section is non-normative. >> >> ... >> >> Adding support for this to existing name server implementations is >> relatively easy, but does require source code modifications. On the >> client, the call to connect() is replaced with a TFO aware version of >> sendmsg() or sendto(). ... > > i object to the use of UNIX syscalls being used to describe a > protocol, even non-normatively. > > let me close by quoting my final remarks in the review of > [Connection-Oriented-DNS]: > > -------- > the backdrop of these comments is that the DNS is a large, complex, > and mostly-working system. as the stewards of its protocol, we have > an obligation to do no avoidable harm. since a TCP/53 listener may > have been developed and deployed by someone not within the sound of > DNSOP's voice today, but who faithfully followed the unfortunate > advice in RFC 1035 regarding TCP connection management, we have to > respect their choices. what that really means is we have to avoid > saturating their small TCP connection capacity (as managed by their > long session timeouts) since that TCP capacity is the only hope of > any UDP initiator who hears TC=1 from them. i argue that while any > attacker can take down that TCP capacity at will with a trivial > one-line perl script, that does not give us the right to take it down > willfully, by using persistent TCP by default. > > -------- > > see also: > > http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/ > > http://queue.acm.org/detail.cfm?id=1242499 so, yes, we "must." -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
