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

Paul Vixie <> Wed, 11 November 2015 16:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2A8FA1B2B83 for <>; Wed, 11 Nov 2015 08:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 58mLhoIM6SJL for <>; Wed, 11 Nov 2015 08:26:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 637701B2B84 for <>; Wed, 11 Nov 2015 08:26:30 -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 A3AF313B53; Wed, 11 Nov 2015 16:26:29 +0000 (UTC)
From: Paul Vixie <>
To: Tony Finch <>
Date: Wed, 11 Nov 2015 08:26:28 -0800
Message-ID: <4611426.Grkv5enuug@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: <> <2974092.InZ2j6Ioop@linux-85bq.suse> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart7910841.rbrxLv9XQ0"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, 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 16:26:32 -0000

On Wednesday, November 11, 2015 03:56:31 PM Tony Finch wrote:
> Paul Vixie <> wrote:
> > 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...
> You get the entire CNAME chain in the first RTT so you can validate all
> the links in the chain in the second RTT.

here, you appear to be planning for a stub validator, which makes RD=1 queries. in a 
recursive caching validator, it would only receive CNAME chains of length>1 for in-zone 
CNAME's or CNAME's that cross zones where both the source and destination zones are 
served by the authority server you happen to be speaking to at the moment. for RFC 2317 
that's almost never the case.

> > can't flood the channel.
> In most cases this will be four or six concurrent queries which is hardly
> flooding the channel. ...

yes, that's flooding the channel. you're allowed one work-stream per query, in order that 
timeouts and other loss are only felt as backpressure by those apps who caused them.

> This is comparable to the TCP initial window or the
> burst of SYNs you get when a browser starts fetching a page full of
> images.
> Browsers send a lot of concurrent queries. My experience with adns tells
> me that concurrent queries work nicely at volumes orders of magnitude
> bigger than we are considering here.

these aren't browsers, those aren't web servers, and i'm not talking about TCP.

> If you already have a TCP channel open you can send all the queries with
> one write and they'll happily fit in a single segment.

i have no objection to multiple parallel outstanding upstream queries over a TCP stream.

P Vixie