Hi Paul, No oars - just a bit of a broken paddle.
On 7/07/2014 2:14 pm, "Paul Vixie" <[email protected]> wrote: > > >right now, root name servers are part of an explicit, hand-maintained >NOTIFY tree. thus, all internet actions depending on root zone content >have up-to-the-minute data if not up-to-the-second data in many cases. we >should treat this as an invariant, which means > any IETF recommendation for root zone slave service should include an >explicit NOTIFY tree, though i doubt it can be either "hand maintained" >as the current one is nor "remember everybody who has fetched it and >NOTIFY all of them" as you suggest. (since many > RDNS servers are behind firewalls or NAT or both, it's fair to say that >most could never hear a NOTIFY.) Terry thinking aloud: it might be palatable to have a automated registration process where a 'root zone enabled resolver' registers with a 'zone distribution service' and issue a keep-alive, such that the ZDS might be able to issue a notify (of sorts) to the resolver.. But getting ahead of myself, the underlying issue of zone freshness (as I've mentioned before) is my break-point. And the environment we have now simply doesn't help that, inclusive of NAT effects. > >thus my preference for the root server anycast proposal first described >in 2005 at > > >https://ss.vix.su/~vixie/alternate-rootism.pdf ><https://ss.vix.su/~vixie/alternate-rootism.pdf> (btw this needs to be http, https asks for auth!) > >and then described again this year for the ICANN ITI panel report (see >section 9.4) at > > >https://www.icann.org/en/system/files/files/report-21feb14-en.pdf ><https://www.icann.org/en/system/files/files/report-21feb14-en.pdf> > >and then described again this week for the IETF DNSOP wg at > > >https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt ><https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt> I'm not going to make statements of the above on technical feasibility, but I am more than concerned about: (sec 3.) The proposed architecture is strongly based on the widely deployed DNSSEC. .. not that is based on DNSSEC, the premise of 'widely', and that serves as a unilateral go signal. I would suggest that timing might well be the impeding factor here. I still see some 6-10K queries/per sec (diurnal pattern) on L-root without the DO bit set. That isn't insignificant as L is only 1 of the 13. So while 'widely deployed' could be argued (23K-31K qps with DO bit) I think 'near pervasive' is the buy-in point. I might well be with you if the omission of the DO bit was at similar or lower levels as the v6 query rate - 2k qps, non-dirurnal. ;) Or maybe the new service addressees in scalingroot-00 MUST only answer to DNSSEC queries..but that is a stretch IMHO. Cheers Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
