Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05

Sara Dickinson <sara@sinodun.com> Tue, 26 January 2016 14:10 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 07D0E1A8FD5 for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2016 06:10:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 VrW-qD-16MxC for <dnsop@ietfa.amsl.com>; Tue, 26 Jan 2016 06:10:22 -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 DCD7B1A8F4F for <dnsop@ietf.org>; Tue, 26 Jan 2016 06:10:21 -0800 (PST)
Received: from [62.232.251.194] (port=30889 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from <sara@sinodun.com>) id 1aO4Jk-00061O-9c; Tue, 26 Jan 2016 14:10:11 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_F06E9884-66BC-4BC8-ACA0-23FADAB8AA12"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <56A72606.7080600@bogus.com>
Date: Tue, 26 Jan 2016 14:10:00 +0000
Message-Id: <7D94546B-6549-4EA4-897D-5FCD56136322@sinodun.com>
References: <568E8479.9090400@bogus.com> <56A0FBB2.6000403@gmail.com> <E1AA00BE-9B1E-47FC-BB27-D36296DDC60D@cisco.com> <56A72606.7080600@bogus.com>
To: joel jaeggli <joelja@bogus.com>
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-1.9
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
X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/0zkS1ZUWwwW9Wo4mG7xao822sus>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>, "dnsop-chairs@tools.ietf.org" <dnsop-chairs@tools.ietf.org>, 🔓Dan Wing <dwing@cisco.com>
Subject: Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05
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, 26 Jan 2016 14:10:25 -0000

> On 26 Jan 2016, at 07:53, joel jaeggli <joelja@bogus.com> wrote:
> 
>> 
>> For DNS-over-DTLS-over-UDP, we should not need to negotiate the
>> client or server capability to send multiple DNS queries over the
>> same DTLS connection; the mere act of negotiating DTLS indicates the
>> ability to handle subsequent DNS queries using that same DTLS
>> connection.  The same might also be true of DNS-over-TLS-over-TCP, in
>> fact?  I mean, is there a client or a server that wants to use
>> DNS-over-TLS-over-TCP and _not_ also have the ability to keep their
>> TCP connection alive for later DNS queries over that same TLS
>> connection?  Perhaps for both DNS-over-TLS, and DNS-over-DTLS, the
>> semantics of edns-tcp-keepalive are implied?
> 
> that is an interesting reading. though I'd want to hear an implementor
> or two say they interpreted it that way.

The DNS-over-TLS draft (https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-05) discusses this explicitly in section 3.4:

“Whereas client and server implementations from the [RFC1035 <https://tools.ietf.org/html/rfc1035>] era are
   known to have poor TCP connection management, this document
   stipulates that successful negotiation of TLS indicates the
   willingness of both parties to keep idle DNS connections open,
   independent of timeouts or other recommendations for DNS-over-TCP
   without TLS.  In other words, software implementing this protocol is
   assumed to support idle, persistent connections and be prepared to
   manage multiple, potentially long-lived TCP connections."

And then informationally references edns-tcp-keepalive and a mechanism that may be useful in signalling idle timeouts for long-lived TCP connections.

Sara.