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. > > There are several advantages and disadvantages to the increased use > of TCP as well as implementation details that need to be considered. > This document addresses these issues and therefore extends the > content of [RFC5966], with additional considerations and lessons > learned from new research and implementations > [Connection-Oriented-DNS]. i object to this reference. [Connection-Oriented-DNS] is a controversial paper, which i've reviewed separately, and should not be referenced in standards work. > 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.3.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." > If a server finds that a client has closed a TCP session, or if the > session has been otherwise interrupted, before all pending responses > have been sent then the server MUST NOT attempt to send those > responses. Of course the server MAY cache those responses. this is a no-op, since there would be nobody to send the responses to. i recommend deleting this paragraph. > 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 paul vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
