Re: Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd)

I think it should be made clear that it is fine for clients to use TCP
keepalive without this spec, and servers must support that. (This is
particularly handy for asynchronous bulk DNS lookups with software like
adns which uses at most two sockets.) My understanding is what this spec
is supposed to do is to (1) allow servers to close TCP connections more
aggressively than RFC 1035 says, and (2) signal to clients how long they
can expect idle connections to last. I think (1) should be allowed
regardless of any explicit signalling.

Section 3.2.2: Use by DNS Clients - Receiving Responses

   A DNS client that receives a response using TCP transport that
   includes the edns-tcp-keepalive option MAY keep the existing TCP
   session open.

I would prefer this to say:

   A DNS client that receives a response using TCP transport MAY
   keep the existing TCP session open whether or not the response
   includes the edns-tcp-keepalive option.

   A DNS client that receives a response using TCP transport that
   includes the edns-tcp-keepalive option SHOULD close an idle
   connection within the period given in the TIMEOUT value.

The idea in this second paragraph is to encourage clients to take care of
the connection's FIN-WAIT-2 state.

Section 3.3.2: Use by DNS Servers - Sending Responses

This section is problematic. Absence of a edns-tcp-keepalive option should
not imply that keepalive is not allowed, since that is an incompatible
change to existing requirements. I think it would be better if no
keepalive were signalled with a edns-tcp-keepalive timeout of zero, and
indefinite keepalive by omitting the option (since this is an undefined
timeout not an infinite one, because infinite is impossible).

Even if the timeout is zero this should still be an *idle* timeout, and we
should keep the RFC 1035 requirement that the server "should delay closing
its end of the connection until all outstanding client requests have been
satisfied." Perhaps there is an opportunity to allow servers to kill
active connections: a TIMEOUT value of zero could mean "this is the last
response on this connection; gotta close it. if you were expecting any
more responses they have been discarded, sorry!". But my guess is that
aggressively closing active TCP connections will lead to increased load
because of connection thrashing.

So I suggest deleting the last paragraph of section 3.2.2, which describes
how clients should interpret a zero timeout, and I suggest the following
text to replace the whole of section 3.3.2:

   The existing DNS specifications state that DNS servers MUST support
   multiple DNS transactions on a single TCP connection. They MAY close
   idle connections, but they SHOULD NOT close the connection until all
   client requests have been satisfied.

   DNS servers MAY include the edns-tcp-keepalive option in responses
   sent using UDP transport to indicate to the client the TIMEOUT value
   it might expect if it was to open a TCP session with the server and
   receive a response with the edns-tcp-keepalive option present.

   DNS servers MAY include the edns-tcp-keepalive option in responses
   sent using TCP transport to signal how long they are willing to keep
   idle connections open. Servers MUST specify the TIMEOUT value that is
   currently associated with the TCP session. It is reasonable for this
   value to change according to local resource constraints.  The DNS
   server can set the TIMEOUT value to zero to indicate that it intends to
   close the connection as soon as there are no more outstanding requests.

Section 3.6: Anycast Considerations

This seems excessively pessimistic about the stability of anycast routing.
It works OK for HTTP, so why not DNS over TCP? A short TIMEOUT should be
fine.

Section 4: Security Considerations

This is nonsense! The edns-tcp-keepalive option makes no difference to the
ability of clients to make large numbers of concurrent requests.

I think this section could discuss points like:

* Good: this spec explicitly allows servers to close connections more
aggressively in order to avoid resource exhaustion, which improves the
availability of servers in overload situations.

* Risk: servers and clients must not treat timeout values as strong
commitments - the server is always allowed to close connections early to
reclaim resources.

* Risk: closing connections too early may lead to connection thrashing
which may increase load

* Risk: servers that close connections have to keep a TCP control block in
memory to keep track of the FIN-WAIT-2 period, so it is generally
preferable for the client to close the connection and handle FIN-WAIT-2.
Good: this spec gives clients a clear indication of when they should close
connections.

* Advice: perhaps there should be something about the extra memory
resources used by tcp connection buffers.

Tony.
-- 
f.anthony.n.finch  <[email protected]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext