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

[Tony Finch <[e-mail]>]

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!

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.

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.