Subject: [DNSOP] [TCP] edns-tcp-keepalive, and 5966bis

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 28 Feb 2015 18:27:52 +0100

[Reflections of the week-end.]

There have been some discussions
(<http://www.ietf.org/mail-archive/web/dnsop/current/msg13170.html> or
<http://www.ietf.org/mail-archive/web/dnsop/current/msg13203.html>) in
juanary on draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close. I've seen no discussion of their
interaction with draft-ietf-dnsop-5966bis. Basically, both
draft-ietf-dnsop-edns-tcp-keepalive and
draft-bellis-dnsop-connection-close try to improve signalling between
the DNS client and the server, while draft-ietf-dnsop-5966bis say that
clients and servers can do what they want with connections and the
other party should be ready to deal with it.

Since we always have to manage broken software and network glitches,
DNS programs will have to handle bad clients and servers, anyway. If
so, what is the point of having a better signalling? Is it worth the
cost (in implementation, and WG time)? Shouldn't we focus only on
5966bis and drop the two others?

Otherwise, three typos in
draft-ietf-dnsop-edns-tcp-keepalive-01:

* "truncacated" instead of truncated

* "that that specific TCP session" (too many thats)

* "indefinately" instead of indefinitely

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Feb 2015 10:04:31 -0800

> Stephane Bortzmeyer <mailto:[email-masked]>
> Saturday, February 28, 2015 9:27 AM
> ...

no. please do not change recommended initiator behaviour in ways that
violate reasonable assumptions of current responders. if the client
wants to keep a connection open longer than it takes to send and receive
the queries they have on-hand, they should find out whether the server
agrees with this incompatible change to the connection management logic
described in RFC 1035 4.2.2.

-- 
Paul Vixie