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

[Paul Vixie <[e-mail]>]

On Tuesday, November 10, 2015 09:29:30 PM Tony Finch wrote:
> Paul Hoffman <[e-mail]> 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.
> > 
> > I'm confused. How does the stub know all of those ahead of time?
> 
> The possible delegation points are where the dots are in the QNAME.
> 
> Tony.

i've watched this go back and forth, while changing planes, trains, and automobiles. 
(greetings from amsterdam! and yes, istanbul was lovely!)

first, i don't think you mean dots. paul\.vixie.redbarn.org is three labels but only two 
possible delegation points. if you mean label boundaries you have to say label boundaries, 
because dots can appear inside labels.

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 can't flood the channel. stubs might do so, at their peril, but will be rate limited if 
they exceed channel capacity to their RDNS (for cache hits) or above their RDNS (for 
cache misses). validators, on the other hand, must not generate background queries in 
bursts. unless bufferbloat is happening, most microbursts will be lossy, and if bufferbloat 
is happening, microbursts will make everything else worse.

each currently-in-progress query inside a validator (or indeed, any RDNS or proxy) must 
make at most one upstream query at a time, and use the network's RTT as its rate limit. 
otherwise you're hosing yourself and everyone else.

there are a lot of great reasons why chain queries are necessary. there is in fact no other 
way to do what they do.

-- 
P Vixie