Re: Hey, SiteFinder is back, again...

Mark,

On Nov 5, 2007, at 5:31 PM, Mark Andrews wrote:
> 	All you have to do is move the validation to a machine
you
> 	control to detect this garbage.

You probably don't need to bother with DNSSEC validation to
stop the  
Verizon redirection.  All you need do is run a caching
server.

> 		dnssec-enable yes;
> 		dnssec-validation yes;
> 		forward only;
> 		forwarders { <Verizon's caching servers>; };

Why bother forwarding?

> 		dnssec-lookaside . trust-anchor <dlv
registry>;

You forgot the bit where everybody you want to do a DNS
lookup on  
signs (and maintains) their zones and trusts and registers
with <dlv  
registry> (of which there is exactly one that I know of
and that one  
has 17 entries in it the last I looked).   You also didn't
mention  
that everyone doing this will reference the DLV registry on
every non- 
cached lookup.  Puts a _lot_ of trust (both security wise
and  
operationally) in <dlv registry>...

> 	All lookups which Verizon has interfered with from
signed zones
> 	will fail.

Yeah, and Verizon customers would get a timeout (after how
long?)  
instead of a more quickly returned A (or maybe a AAAA) RR to
a  
Verizon controlled search engine.  Not really sure the cure
is better  
than the disease.  Also not sure what the point is -- most
common  
typos are already squatted upon and validly registered to a
adsense  
pay-per-click web page, typically a search engine (e.g.,  
www.baknofamerica.com).  Seems to me the slimeballs have won
yet  
again...

Regards,
-drc

> Mark,
> 
> On Nov 5, 2007, at 5:31 PM, Mark Andrews wrote:
> > 	All you have to do is move the validation to a
machine you
> > 	control to detect this garbage.
> 
> You probably don't need to bother with DNSSEC
validation to stop the  
> Verizon redirection.  All you need do is run a caching
server.

	Yep.
 
> > 		dnssec-enable yes;
> > 		dnssec-validation yes;
> > 		forward only;
> > 		forwarders { <Verizon's caching servers>;
};
> 
> Why bother forwarding?

	It was just to prove that you could detect this coming out
	of a ISP's servers.
 
> > 		dnssec-lookaside . trust-anchor <dlv
registry>;
> 
> You forgot the bit where everybody you want to do a DNS
lookup on  
> signs (and maintains) their zones and trusts and
registers with <dlv  
> registry> (of which there is exactly one that I know
of and that one  
> has 17 entries in it the last I looked).   You also
didn't mention  
> that everyone doing this will reference the DLV
registry on every non- 
> cached lookup.  Puts a _lot_ of trust (both security
wise and  
> operationally) in <dlv registry>...

	There are also other lists of trust anchors.

	With 17 entries there arn't a lot of queries that need to
	be made to have the entire name space covered by cached
	NSEC records which DLV will use.
 
> > 	All lookups which Verizon has interfered with
from signed zones
> > 	will fail.
> 
> Yeah, and Verizon customers would get a timeout (after
how long?)  
> instead of a more quickly returned A (or maybe a AAAA)
RR to a  
> Verizon controlled search engine.  Not really sure the
cure is better  
> than the disease.

	But then you can log a complaint that DNSSEC doesn't work
	using their caching resolvers.  Or this just gives you
	the heads up to find the web form to change the servers
	returned by DHCP.  There is contributed code to do this
	linkage for BIND.  Or to manually update the forwarders.

	i.e. it's useful for those who use ISP's that havn't yet
	gone over to the dark side. 

> Also not sure what the point is -- most common  
> typos are already squatted upon and validly registered
to a adsense  
> pay-per-click web page, typically a search engine
(e.g.,  
> www.baknofamerica.com).  Seems to me the slimeballs
have won yet  
> again...

	That's a different issue on a different battle front.
 
	Mark

> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET:
Mark_Andrewsisc.org