Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 11 November 2015 05:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 15ACB1A876C for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 21:18:59 -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 jSKDH3M4oCXW for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 21:18:58 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135531A8754 for <dnsop@ietf.org>; Tue, 10 Nov 2015 21:18:57 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E2D15283B22; Wed, 11 Nov 2015 05:18:56 +0000 (UTC)
Date: Wed, 11 Nov 2015 05:18:56 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20151111051856.GV18315@mournblade.imrryr.org>
References: <5635CF1A.4030803@gmail.com> <alpine.LSU.2.00.1511091301260.25050@hermes-2.csi.cam.ac.uk> <A8A3F4DA-EE53-4BA4-9EF7-6DCB6120350B@vpnc.org> <alpine.LSU.2.00.1511091651330.25050@hermes-2.csi.cam.ac.uk> <E78EC567-FE6A-41B5-92DF-084145171455@vpnc.org> <alpine.LSU.2.00.1511102129030.24500@hermes-2.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.1511102129030.24500@hermes-2.csi.cam.ac.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/_3wuxrNOcENT7p1XVT7Lcb7pu2w>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dnsop@ietf.org
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: Wed, 11 Nov 2015 05:18:59 -0000

On Tue, Nov 10, 2015 at 09:29:30PM +0000, Tony Finch wrote:

> Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> > > With the current DNS protocol, a stub resolver can get all the records it
> > > needs to validate a response in 1RTT, by sending multiple concurrent
> > > queries for all the possible delegation points in the QNAME.
> >
> > I'm confused. How does the stub know all of those ahead of time?
> 
> The possible delegation points are where the dots are in the QNAME.

Except in the presence of CNAME (possibly via DNAME) records, which
might mean that the client needs more records to validate multiple
nodes in the DNS tree.

So without nameserver assistance 1RTT via parallelism is not always
possible.

-- 
	Viktor.