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

Paul Vixie <> Wed, 11 November 2015 14:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4642A1ACE84 for <>; Wed, 11 Nov 2015 06:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_BACKHAIR_31=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gfy_oDq0CTum for <>; Wed, 11 Nov 2015 06:36:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8B9D1ACE0C for <>; Wed, 11 Nov 2015 06:36:54 -0800 (PST)
Received: from linux-85bq.suse (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id B53691814C; Wed, 11 Nov 2015 14:36:53 +0000 (UTC)
From: Paul Vixie <>
Date: Wed, 11 Nov 2015 06:36:52 -0800
Message-ID: <2974092.InZ2j6Ioop@linux-85bq.suse>
Organization: Vixie Enterprises
User-Agent: KMail/4.14.10 (Linux/4.1.12-1-default; KDE/4.14.10; x86_64; ; )
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart2769534.2hyacVn1TS"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: Tony Finch <>, Paul Hoffman <>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2015 14:36:56 -0000

On Tuesday, November 10, 2015 09:29:30 PM Tony Finch wrote:
> Paul Hoffman <> 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.
> Tony.

i've watched this go back and forth, while changing planes, trains, and automobiles. 
(greetings from amsterdam! and yes, istanbul was lovely!)

first, i don't think you mean dots. paul\ is three labels but only two 
possible delegation points. if you mean label boundaries you have to say label boundaries, 
because dots can appear inside labels.

second, you can't send a burst of queries, as a validator. even apart from the fact that any 
CNAME (RFC 2317 style) can add delegation points that weren't at label boundaries in 
your original QNAME, and there can be more than one of these, so you're not at RTT=1 or 
even RTT<=2, you're at RTT>0 without knowing the upper bound... can't flood the channel. stubs might do so, at their peril, but will be rate limited if 
they exceed channel capacity to their RDNS (for cache hits) or above their RDNS (for 
cache misses). validators, on the other hand, must not generate background queries in 
bursts. unless bufferbloat is happening, most microbursts will be lossy, and if bufferbloat 
is happening, microbursts will make everything else worse.

each currently-in-progress query inside a validator (or indeed, any RDNS or proxy) must 
make at most one upstream query at a time, and use the network's RTT as its rate limit. 
otherwise you're hosing yourself and everyone else.

there are a lot of great reasons why chain queries are necessary. there is in fact no other 
way to do what they do.

P Vixie