Sitefinder II, the sequel...

Simon Waters simonw at zynet.net
Tue Jul 11 08:06:55 UTC 2006


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?



More information about the NANOG mailing list