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

[Tony Finch <[e-mail]>]

Ólafur Guðmundsson <[e-mail]> wrote:
> On Mon, Nov 9, 2015 at 12:52 PM, Evan Hunt <[e-mail]> wrote:
> > On Mon, Nov 09, 2015 at 04:55:24PM +0000, Tony Finch 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.
> >
> > But has to retain state for all those active queries, which adds a fair
> > bit of complexity.  I would expect it to be a lot more straightforward to
> > code a stub validator using CHAIN.
>
> In deep zones like the reverse zones the stub has no idea where the zone
> cuts are thus this idea is work reduction for the stub

Yes, this is true, and edns-chain-query also reduce bandwidth use.

However the only benefit of edns-chain-query claimed in the abstract is
reduced latency and this is completely wrong.

WRT complexity, from the validation code I have looked at, the main
problem (in multiple validators in multiple languages) is that the
validation process is too finely interleaved with the query process, and
you would have to disentangle them to make good use of edns-chain-query.
But once you have done that it is pretty easy, and a LOT more
interoperable, to send concurrent queries.

Note that finding zone cuts is not relevant to latency: if you send
concurrent queries for all possible cuts you will find out in 1RTT where
the cuts are and all the information you need for validation. What
edns-chain-query reduces is the bandwidth for the non-zone-cut queries and
responses, and the work of separating the relevant and irrelevant
responses.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Viking, North Utsire: Westerly or southwesterly 5 or 6, occasionally 7 later.
Moderate or rough. Rain or squally showers. Moderate or good, occasionally
poor.