i am not joe, but i strongly +1'd his response on this thread, so i'm putting my oar back into the water now.
Mark Andrews wrote: > In message <[email protected]>, Joe Abley > writes: >> >> 5.1. Pros >> >> o Junk queries / negative caching - Currently, a significant number >> of queries to the root servers are "junk" queries. Many of these >> queries are TLDs that do not (and may never) exist in the root >> Another significant source of junk is queries where the negative >> TLD answer did not get cached because the queries are for second- >> level domains (a negative cache entry for "foo.example" will not >> cover a subsequent query for "bar.example"). >> >> I think a better way to accommodate the second point is to implement >> qname minimisation in recursive server logic. > > When you can get rid of all the servers in the world which followed > RFC 2535 which return NXDOMAIN for empty non terminal qname > minimisation and this sort of logic will be viable query minimization is very much worth having for its own sake. RFC 2535 style authorities were never numerous. we can cope. > though it won't > do anywhere as near as good a job as having a local copy of the > root zone. there are far more errors encountered below .com or .de than by their siblings in the root. any argument in favour of wide scale slaving of the root zone begs the question, why not every tld and every pseudo-tld (such as no-ip.org)? the root isn't special in regards to a goal of preventing junk queries. that's why query minimization is the preferred solution to this problem. > ... > >> There's an implication here that a recursive resolver sending a query to >> a root server is potentially impinging upon the privacy of its anonymous >> clients. I find that a bit difficult to swallow. > > Given the intelligence that root server operators have glenned in the past > there is a degree of credability here. if it were possible to put in place agreements between the root name server operators and the internet community, one of the things i'd ask for is a "no data mining" rule. that is, i would want to be sure that verisign's security business was in no way commercially advantaged by its exclusive access to the a/j root query stream (or the .com query stream). alas, that's the third rail of internet politics, and i have no wish to place a moist body part up against it. to your actual point, query minimization is the solution to data leaks into root, and tld, and pseudo-tld authorities. slaving the root zone only solves this problem for the root name server operators, who are nowhere near our full problem statement with regard to long-qname surveillance. > > >> A new root zone is published usually two (but sometimes more) times per >> day. The semantics specified in the draft for refreshing a local copy of >> the root zone say "keep re-using the copy you have until it expires". If >> I assume that "expire" means "survives beyond SOA.EXPIRE seconds of when >> we originally fetched it", then there's the potential for stale data to >> be published for a week plus however old the originally-retrieved file >> was (which is difficult to determine, in contrast to the traditional root >> zone distribution scheme). I think this disadvantage is more serious than >> is presented. > > > Slaves perform refresh queries every 30 minutes (refresh = 1800). > Oops actually clear up faster with slaves than without as many of > the responses are now direct to stub rather than cached responses > which have much higher TTLs. > > If one was really worried one could keep a log of the last 24 hours > of zone tranfers and issue a NOTIFY to all of the sources that > transfered the zone. Normal refresh logic would then kick in for > a large percentage of slaves. This is permitted by the RFC's. > Machines are actually good at doing this sort of thing. > > This is actually a pro not a con. 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.) i like the cost and complexity and likely error rate of an explicit NOTIFY tree involving a few thousand anycast slaves each operated by someone who knows the technology and is aware of their role in the system, far more than i like the cost and complexity and likely error rate of an explicit NOTIFY tree involving tens of millions of RDNS systems mostly operated by people who do not understand the issues and have no idea what their role in the system is. thus my preference for the root server anycast proposal first described in 2005 at https://ss.vix.su/~vixie/alternate-rootism.pdf 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 and then described again this week for the IETF DNSOP wg at https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt briefly, it means recommending hierarchical anycast root service be deployed on loopback networks, LANs, campus networks, ISP's, and globally, by anyone with motivation and capacity, including the existing root name server operators. a small number (a few hundred or a few thousand) such root anycast operators would have global impact on root zone content reachability. > > In the 10+ years I have been slaving the root zone I have not once needed > to trouble shoot it. Trouble shooting a slaving the root is no different > to trouble shooting any other slave zone. mark, you have in the last ten years debugged somebody else's DNSSEC configuration error with two or three "dig" commands that i would never have thought of and could not have interpreted as you did. and i used to be smart. therefore any statement of the form "mark andrews finds this easy and has never had a problem with it" is to me neither indicative nor dispositive. vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
