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

Paul Wouters <[email protected]>
Newsgroups gmane.ietf.dnsext
Message-ID <[email protected]>
On Wed, 16 Oct 2013, Tony Finch wrote:

> 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.

Historically, DNS transactions over TCP only handle 1 query/answer.

That's not what the specification was supposed to mean, but that's what
it has become in practise. Joe and I therefor thought it would be best
to leave that existing deployment as-is, and use a new option to clearly
unambiguously indicate that yes we will actually allow more than one
query and actively encourage it. That was our number one goal.

So while we don't disagree with you that implementators could fix that,
we thought it would be error prone to change that. It would be
impossible to distinguish between old unpatched DNS software and new
patched DNS software. This new option makes it abundantly clear. It
avoids mismatched expectations between DNS clients and DNS servers.

And while doing so, allows us to warn DNS clients about idle TCP
connections, as we expect that a lot of load balances would interfere
with long outstanding TCP sessions that would require a special signal
to the DNS clients not to linger too long.

We will look at your proposed changes, especially the security section
ones, and merge in what seems appropriate. But unless I hear more people
who would favour making the new option more "optional" I think we should
stick to this more clear cut of the undefined past behaviour.

Paul
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.