Re: [DNSOP] OPS-DIR review of draft-ietf-dnsop-edns-tcp-keepalive-04

Sara Dickinson <sara@sinodun.com> Tue, 05 January 2016 17:40 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070B41ACEA6 for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2016 09:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXQxBULrQmrk for <dnsop@ietfa.amsl.com>; Tue, 5 Jan 2016 09:40:50 -0800 (PST)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59211ACE6F for <dnsop@ietf.org>; Tue, 5 Jan 2016 09:40:50 -0800 (PST)
Received: from [62.232.251.194] (port=2882 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from <sara@sinodun.com>) id 1aGVb9-0004PD-Cx; Tue, 05 Jan 2016 17:40:44 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <50A39518-E8EC-4F4D-9198-94CCDAC17FBC@sinodun.com>
Date: Tue, 05 Jan 2016 17:40:46 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F40B01F-C8F7-43C6-B7E1-5CA582A13819@sinodun.com>
References: <20151222184313.GA20045@puck.nether.net> <50A39518-E8EC-4F4D-9198-94CCDAC17FBC@sinodun.com>
To: Jon Mitchell <jrmitche@puck.nether.net>
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/5q6x_tVECDIGxRODjXEdh7UAO2Q>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, joel jaeggli <dnsop@ietf.org>
Subject: Re: [DNSOP] OPS-DIR review of draft-ietf-dnsop-edns-tcp-keepalive-04
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2016 17:40:52 -0000

> On 23 Dec 2015, at 13:30, Sara Dickinson <sara@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.