In message <[email protected]>, Paul Vixie writes: > > 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 wri > tes: > >> > >> 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.
Even with query minimization you will still gets lots of junk queries to the roots. > > 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. The root scales at present. > > ... > > > >> 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. query minimization only addresses part of the issue, usually that of having .corp in a search list (or similar) when not talking to a recursive server with a .corp configured. It does not address the issue of stub resolvers appending "." to single labels when searching. > >> 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.) Today if the root gets stuffed content it takes 2 days to clear from the system. With slave copies of the root only using SOA timers it would take 30 minutes to clear to bad data. By the time you get around to publishing a "flush your cache" notice and having even a small percentage know with current procedures the bad data is gone with slaves. > 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. The key words was "not once needed to trouble shoot". > vixie > > --------------060203040002090505050401 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > <html><head> > <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> > </head><body bgcolor="#FFFFFF" text="#000000">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.<br> > <br> > Mark Andrews wrote: > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap="">In message <a class="moz-txt-link-rfc2396E" href="mailto:etPan > [email protected]"><etPan.53b82396.4353d0cd.38df@ > walrus.hopcount.ca></a>, Joe Abley writes: > </pre> > <blockquote type="cite"><pre wrap=""> > > 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. > </pre></blockquote> > <pre wrap=""><!----> > 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</pre> > </blockquote> > <br> > <span>query minimization is very much worth having for its own sake. RFC > 2535 style authorities were never numerous. we can cope.<br> > <br> > </span> > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap=""> though it won't > do anywhere as near as good a job as having a local copy of the > root zone.</pre> > </blockquote> > <br> > 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.<br> > <br> > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap=""> > ... > > <blockquote type="cite"><span><pre wrap="">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.</pre></span></blockquote> > </pre> > <pre wrap=""><!---->Given the intelligence that root server operators have > glenned in the past > there is a degree of credability here.</pre> > </blockquote> > <br> > 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.<br> > <br> > 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.<br> > <br> > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap=""> > > > <blockquote type="cite"><span><pre wrap="">A new root zone is published usual > ly 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.</pre></span></blockquote> > </pre> > <pre wrap=""><!----> > 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.</pre> > </blockquote> > <br> > 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.)<br> > <br> > 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.<br> > <br> > thus my preference for the root server anycast proposal first described > in 2005 at<br> > <br> > <a class="moz-txt-link-freetext" href="https://ss.vix.su/~ > vixie/alternate-rootism.pdf">https://ss.vix.su/~vixie/alternate-rootism.pdf</ > a><br> > <br> > and then described again this year for the ICANN ITI panel report (see > section 9.4) at<br> > <br> > <a class="moz-txt-link-freetext" href="https://www.icann.o > rg/en/system/files/files/report-21feb14-en.pdf">https://www.icann.org/en/syst > em/files/files/report-21feb14-en.pdf</a><br> > <br> > and then described again this week for the IETF DNSOP wg at<br> > <br> > <a class="moz-txt-link-freetext" href="https://tools.ietf. > org/id/draft-lee-dnsop-scalingroot-00.txt">https://tools.ietf.org/id/draft-le > e-dnsop-scalingroot-00.txt</a><br> > <br> > 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.<br> > <br> > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap=""> > > 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.</pre> > </blockquote> > <br> > 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.<br> > <br> > vixie<br> > <blockquote cite="mid:[email protected]" > type="cite"> > > </blockquote> > </body></html> > > --------------060203040002090505050401-- > > > --===============1618732303828035307== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > --===============1618732303828035307==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
