On 05/01/16 17:40 +0000, Sara Dickinson wrote: > > > On 23 Dec 2015, at 13:30, Sara Dickinson <[email protected]> wrote: > >> > >> [JM] Sorry, this is my fault on the confusion on the previous two > >> comments - I was actually still confused by section 3.2.1 (not 3.3.2) > >> paragraph 3, why a DNS client would first signal they support the EDNS > >> keepalive then later stop signaling that on the same connection rather > >> than just resetting the connection at some point. This seems like odd > >> behavior by a client. > > > > I think I understand the confusion now. > > > > One key problem this option is trying to solve is that most DNS servers > > today have very poor TCP connection management and if clients simply > > started keeping connections open they could exhaust the server resources > > easily. So the keepalive exchange on the first query allows both parties to > > know that the other end does support keepalive and so keeping the > > connection open is OK. The design here is meant to be as lightweight as > > possible to achieve that goal, and in fact earlier versions simply had the > > exchange of keepalive options on the first query and not at all on > > subsequent ones. > > > > So, the lack of keepalive in subsequent queries isn’t a signal that the > > client doesn’t support keepalive, or doesn’t want to keep the connection > > open, it just isn’t required. > > > > The reason an option was added to allow clients to send the keepalive > > option in a later query on the same connection so the client can check if > > the server has changed (or is willing to change) the timeout it has > > associated with the session. Because of the semantics of EDNS0, DNS > > servers cannot send a keepalive option with an updated timeout in a > > response unless the client sends an EDNS0 option in the query. But we > > didn’t want the overhead of adding the option to every message on the > > connection to achieve that. Hence the discussion in section 3.4 about > > clients periodically resending the option. > > > Just chasing off-list ahead of the IESG tele chat on Thursday :-) > > Does this clarify the background enough? >
Sorry for the delay, absolutely, thanks! Jon _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
