[e2e] Early FIN/close for query-response TCP connections like DNS's

[Stefanos Harhalakis]

Hello,

On Wednesday 13 of October 2010, Alfred Hönes wrote:
> Stefanos,
> regarding your question on TCP connection management for DNS, please
> see RFC 5966 (DNS Transport over TCP - Implementation Requirements).

Thanks for the pointer. I just read it. See comments inline:

> For instance, an end-system resolver (or a DNS forwarder, e.g. in an
> access gateway) that is configured with a single recursive resolver,
> to which it will forward all queries, should preferably keep a TCP
> connection open for considerable time, ideally forever.

This should only apply whenever a stub resolver is involved. If it isn't or 
the client API directly contacts the DNS server (like in linux systems without 
nscd running) then it is not possible to use this kind of keep-alived 
connections (no?).

In that case the client may not benefit from an open connection (e.g. when 
running "dig") or it is not aware of using TCP. I believe that this is the 
case of most implementations that use gethostbyname() (or similars) without 
using sethostent(1). Since gethostbyname() will retry using TCP whenever the 
UDP query was truncated and then close the connection, the early FIN would 
work there.

> Unless the server is under serious resource pressure, it should keep
> a TCP connection open for a time span that is comparable to the time
> it would keep the closed connection in TIME-WAIT state.

The proposal (which should apply for all query/reply TCP-based sessions) only 
affects clients. Server-side would only benefit from clients that early-close. 
The decision for early-closing the connection is a client-side decision which 
in many cases is already aware of whether it will keep the connection open.

The server-side implementation only needs to test the socket for reading 
(which I believe it already does if it supports connection keep-alive) and if 
it fails it should close the connection exactly at the point where all data 
are sent.

Am I mistaken in the above rationale?