On Tuesday, November 10, 2015 09:29:30 PM Tony Finch wrote: > Paul Hoffman <paul.hoff...@vpnc.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
