On May 7, 2014, at 3:37 PM, Paul Vixie <[email protected]> wrote: > an rfc is seen by sellers and buyers as an unalloyed good. we can (and i do) > criticize uneducated people making appeals to authority, but that's a far cry > from pretending it won't happen or that any undesirable result from its > happening is not the responsibility of those who write and edit and approve > RFC documents. > > the current thrust is to move from "ietf should do good engineering" to "ietf > should document anything that has to be interoperable", and in that move we > have to plan on being quite detailed in our "applicability statement" > sections. my draft for that section of a client subnet option goes more or > less like this: > > << APPLICABILITY STATEMENT > > The method described in this document is controversial, as is the use of wide > area anycasting for Full Service Resolvers (recursive DNS servers)...
So what if its controversial. Global warming is "controversial". Doesn't mean it isn't happening. And it doesn't mean that "controversial" doesn't mean "shouldn't be done". Giving out different DNS results to different clients is a behavior that is not only well established, but is indeed a good idea. If I have a server in California, and a server in China, I'm going to want my US visitors to go to California, while my asian visitors to China. And anycasted recursive resolvers are a good idea: It allows you to select a DNS provider independent the one forced upon you by the DHCP server (which, with far too many ISPs, is a server which outright lies), and have good performance from that DNS provider. And to Paul's comment to me: > services that don't use CDN, or whose CDN does not use what i call "Stupid > DNS Tricks", won't see any improvement. so, this is a problem created by ADNS > and RDNS operators going off the reservation in the first place, and it only > affects those operators and their customers. Yes, such systems don't see a benefit. But its an option that they can conveniently and safely ignore, so they don't see a cost either. And, no doubt, you will ensure that Bind will never, ever implement it. Who cares? As long as the servers properly handle unknown options (which is something that any server MUST do), this has no effect. As for your "rdns fade" argument: Its actually the opposite. By being centralized, things are more likely to get fixed, which means if you assume error rate per server is the same (and its not, Google runs a much better DNS resolver than 90% of those who instal Bind as a recursive resolver), being big means it actually gets fixed. If random local campus resolvers have issues with a domain name, it won't get fixed, because the domain owner doesn't know about it, and the client sees just a failure. But, if you monitor the Google Public DNS list, you see that resolution failures on the 'big, central point of failure' actually get addressed. Likewise, you see that the "Broken DNSSEC" self-DOS generally doesn't affect users using Comcast DNS or Google Public DNS, even though they are validating servers, because for those servers, the DNSSEC error gets noticed and a temporary override gets put in. Lets see this happen on a world full of small networks running Bind with DNSSEC validation turned on... But, in the end, it doesn't matter. The big DNS operators who would benefit from edns_client_subnet have just gone ahead and done it. It works, its running today, its interoperable (we actually have a python server that supports it even), and it doesn't matter what the IETF thinks. If you want something implemented, do it. If you want to argue about it, with people who object to it on philosophical grounds of enabling "stupid DNS tricks", write an RFC. This discussion is just one more datapoint in the set of "This is why the IETF is where protocols go to die". -- Nicholas Weaver it is a tale, told by an idiot, [email protected] full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
