> 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

Reply via email to