On Tuesday 11 Jul 2006 07:19, Steve Sobol wrote:
There's a big difference, of course, between INTENTIONALLY pointing your computers at DNS servers that do this kind of thing, and having it done for you without your knowledge and/or consent.
Yes, one way you choose who breaks your DNS, the otherway Verisign break it for you. Most people don't have the know-how to understand the consequences of using such a service. So providing it without screaming huge warnings is at best misleading. As someone who works for a company that provides trials of a web hosting product, we've had our share of abusive trial users inventing new ways to abuse our service. But if you try and block this abuse at the DNS level you'll almost certainly break access to every other site we host on that service. Similarly our DNS servers provide short term A records for some important sites, blocking their IP address in the DNS server would result in a loss of redundancy of a fairly major service (okay we use different names for the DNS server and the webserver, but not everyone does that). In this instance it is unlikely the loss of redundancy would be noticed, until it was needed, as by its nature redundancy acts to hide small scale failures. This is the basic issue with DNS changes by third parties; "the third party can have no knowledge of the scope or scale of the issues their changes could cause". That is why the DNS has delegated administration, although there is probably less need for the delegated deployment any more (computers are big and cheap compared to the 1970's), delegated administration is still a MUST have. Think DNS is *sensitively dependent on correct values*. Sure they can try and guess, but it is at best a guess. I note almost all phishing sites use IP address these days anyway, certainly all those I reported this morning were using URLs of the form "http://10.11.12.13/www.example.com/" If you just want faster recursive resolvers, that is easily done without breaking anything, and without risking your view of the DNS. More hardware, slave ".", optimise the binaries (Rick Jones has documented this in huge detail at HPs performance labs), optimise the IP stack etc. If the only value add is fast recursive resolution, but from off your network, I'd suggest this is a poor choice as well, as a key planning decision of DNS resolver deployment is to deploy "within your network" so stuff works when your connectivity is toast (of course that'll never happen). I see no redeeming features of the service, or did I miss something?