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

["Wiley, Glen" <[e-mail]>]

On 11/11/15, 5:01 PM, "Tony Finch" <[e-mail]> wrote:


>Paul Vixie <[e-mail]> wrote:
>> On Wednesday, November 11, 2015 04:41:27 PM Tony Finch wrote:
>> > Paul Vixie <[e-mail]> 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
>>queries
>> > > 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
support 
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.
>
>Tony.
>-- 
>f.anthony.n.finch  <[e-mail]>  http://dotat.at/
>Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8. Rough or
>very
>rough, becoming very rough or high. Occasional rain. Good, occasionally
>poor.
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop