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