> On 23 Dec 2015, at 13:30, Sara Dickinson <s...@sinodun.com> 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? Sara. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
