David Conrad wrote: > Paul, > > > ... >> that's why query minimization is the preferred solution to this problem. > > This isn't either/or.
are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? granted, we can solve any given problem in any number of ways including one, or more than one. but what's our incentive to pay more than we have to? > ... one key point of slaving the root is that folks who do slave the root are > accepting the responsibility to keep it up to date. Failure to do so only > impacts their own customer base. This is a self-correcting problem -- get too > stale and your (presumably paying) customer scream at you ... my experience has been that when dns doesn't work the call reporting this can go just about anywhere. if i could be sure that the first call from most users would go to the actual person who had the power to fix whatever caused the call, i'd certainly make that a primary design assumption. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. if you give me a vote, wearing my domain holder hat, i will pick "please tell the small number of people who want to run root anycast nodes to do so" rather than "please tell the large number of RDNS operators to slave the root". this is me wanting, selfishly, uptime and a low number of dependencies and state-permutations. but i consider myself to be representative of other domain holders in this regard, so it could be worth paying attention to my selfish desires this time. vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
