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

"Wiley, Glen" <> Thu, 12 November 2015 16:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 90D841B2A69 for <>; Thu, 12 Nov 2015 08:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LG21dW3Q7xqe for <>; Thu, 12 Nov 2015 08:25:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 881561B2AB6 for <>; Thu, 12 Nov 2015 08:25:34 -0800 (PST)
Received: by qgea14 with SMTP id a14so3885918qge.2 for <>; Thu, 12 Nov 2015 08:25:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :content-type:content-id:content-transfer-encoding:mime-version; bh=9CC39nAI4JccU74ua+Pj+tkqBkIKpXuHYwau290V6D4=; b=baRsqMW7msFU+AV5GozdoccUgXoDrNcb+Nc9uh/Ub3P4GLJm3de7omW5GE8iwdSiwp bVxR34VayeVyOvehhSgXfrNodQf0iuDCOQIWTopOgof6kXXixaC65WsPvNz4AJGUOMDF 37qAuzle7tBU2kLanb64SGHCnHdAbeF4H/SUdoIrFKezNRIBzH23VtBhQOvSrkI1bemt 28PX5TIWe0OQRUpFQPKFBWlO8sa3BFsnhkv1FE8g4OH04FPB5yxM6UuNa86ybNao9TAq Or4XzkWbPuZw4voIipQXdPKHGFomJ9wgU5b6G8an4HpgZvmh3KzlCUnxtc18P4OvxrQ0 0XJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:content-type:content-id :content-transfer-encoding:mime-version; bh=9CC39nAI4JccU74ua+Pj+tkqBkIKpXuHYwau290V6D4=; b=Zbf9QDivPEc973vMhlTaV7SgNh9Id39lkP9CzGFCcqHvVYdDN8XmkxSb55tzHJ3nP0 TlsRe+5yous5tdRNRXlbHLZ+v7EP4GEJbUczDZu8Y8xY1MYTMwuIbhdCkGczPnXYxE2Z AGS2T0kGvR882GIX4HoQUo8eBsTNOXwP/yfOw8Rjij9w7NoHc3b7qxBDmOBq8+XDK5VE 24qaQ4r0/p0xcZ0tlM0Mef0/3FBvy6sNcGkmSOzGfhyEllPT25cBB9b7ZhXSiBnqFzEv WNc/GffdtHxOAS1l+nvy+v4l2I7MztMK+4O1PcMCQJP0Vr5FVYpGfsgbUgVKb7J+B+r2 vV1w==
X-Gm-Message-State: ALoCoQnud/64Fwgm38YmwxspialJVURioY6ekbrM5NZPS00ABxy06a8N6WRTvfb4iLiEUC7bG3CmhC/int3tCYySeUJTLeQlHA==
X-Received: by with SMTP id 79mr17777303qhy.5.1447345533604; Thu, 12 Nov 2015 08:25:33 -0800 (PST)
Received: from ( []) by with ESMTPS id y62sm1184284qka.11.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Nov 2015 08:25:33 -0800 (PST)
Received: from (brn1wnexcas02 []) by (8.13.8/8.13.8) with ESMTP id tACGPWLw022712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 11:25:33 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Thu, 12 Nov 2015 11:25:32 -0500
From: "Wiley, Glen" <>
To: Tony Finch <>, Paul Vixie <>
Thread-Topic: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
Date: Thu, 12 Nov 2015 16:25:32 +0000
Message-ID: <>
References: <> <4611426.Grkv5enuug@linux-85bq.suse> <> <1610388.9fsJffuA5T@linux-85bq.suse> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Thu, 12 Nov 2015 16:25:42 -0000

On 11/11/15, 5:01 PM, "Tony Finch" <> wrote:

>Paul Vixie <> wrote:
>> On Wednesday, November 11, 2015 04:41:27 PM Tony Finch wrote:
>> > Paul Vixie <> wrote:
>> >
>> > > 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.
>> >
>> > Where is that specified?
>> it's written in tire tracks down my backside.
>Sounds painful :-)
>> > > i have no objection to multiple parallel outstanding upstream
>> > > over a TCP stream.
>> >
>> > Why is TCP special?
>> because it has per-flow congestion control.
>Which is perfectly fair, but there is a big difference between saying that
>high-volume DNS clients need congestion control, and saying that they must
>have at most one query outstanding at any time. If you say TCP is OK, you
>are implicitly saying that it's OK to have a window size greater than one
>packet. And that implies there are engineering questions about how that
>window size should be managed.
>And this implies it is unreasonable to forbid concurrent queries over UDP.
>(And it would be futile to break running code in every browser.)
>The upshot of all this is that how you use concurrent queries to improve
>performance without breaking things is a matter of engineering and
>implementation quality.
>And since (as far as I know) no-one has done that engineering, I think it
>is premature to try to deploy a protocol fix for a hypothetical problem.
>(adns's concurrency control is quite simplistic, for example.)
>What edns-chain-query says to DNSSEC users is, DNSSEC still isn't finished
>or ready for deployment on edge devices, and you have to wait another 5 or
>10 years for another protocol change to be deployed before you can get
>decent performance.
>This is wrong!

Another way to read the message of edns-chain-query is: DNSSEC has many use
cases and operation implications.  If you would like an alternate path
that may reduce latency under some conditions but not compromise the
security of the query/response here is one way to tackle it.

>In order to make edns-chain-query work, validators will need to be
>refactored to decouple the validation logic from the network chatter. At
>the moment there aren't APIs that let you present a chain of DNSKEY and DS
>RRsets to a validator and get an assessment. The current model is
>"validate this RRset please" and then wait for a dozen RTTs.

At this stage there aren¹t widely deployed validating stub resolvers.
This is
true of new technology in general - I don¹t think the bar for improvements
should be ³has this already been implemented?²

There are some budding ideas and implementations out there, but any
for DNSSEC on the client/host currently requires changes to the host APIs.

>But once you have a validator API that works with edns-chain-query you
>also have a validator API that works with concurrent queries on the
>existing DNS.
>So really we should be trying to make that work first, since it has a much
>more compelling deployment story.
>And if well-informed engineering makes it clear that the existing DNS
>can't reliably handle 6 ish concurrent queries, then maybe it's time to
>think about upgrading everything with a new protocol feature.
>f.anthony.n.finch  <>
>Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8. Rough or
>rough, becoming very rough or high. Occasional rain. Good, occasionally
>DNSOP mailing list