[dns-operations] the mathematics of kaminsky spoofing probability

Shane Kerr shane at ca.afilias.info
Wed Aug 6 08:51:20 UTC 2008


On Tue, 2008-08-05 at 16:51 -0700, Eric Osterweil wrote:
> 
> I was curious why you think the registry and the registrar must  
> support DNSSEC in order for you to gain protection from it?  If I  
> understand your implication, it is because the parent zones must  
> securely delegate (i.e. serve valid DS records) for the secure  
> children, right?  If I've misunderstood you, my appologies.  However,  
> if this is the case, I think you might find that it really takes 2  
> (maybe 3) parties, and if you run a recursive resolver, then you are  
> one of them. ;)

Yes, my thinking is that if the registry does not support DNSSEC, I
cannot get a DS record into that zone. And most registries require all
interaction to go through a registrar, which must also support this.

I assure you nobody is going to put the keys for my vanity domain into
their list of trust anchors.

> > So, for those of us who are not lucky enough to live in Sweden or
> > Brazil, a little forgery resistance is a good thing. :)  (I guess,  
> > since
> > of course I have not seen the official publication.)
> 
> To use DNSSEC in the absence of a delegation hierarchy you can look  
> at DLV repositories.  From RFC 5074 S07, "... Searching all  
> applicable DLV domains until an applicable DLV record is found that  
> results in a successful validation of the response... "
> 
> Thus, you can use DLV and keep this a 2 party operation (as zones  
> adopt DNSSEC, they get into DLV repos at different rates).

Well, 3 parties if you count the DLV operator.

We are a long way from having very many resolvers use DLV - most don't
even support DNSSEC (at least not by default). It's kind of a question
as to whether the long, slow process of getting resolvers updated will
go faster than the long, slow process of getting zones signed (I expect
we will have zones signed faster, to be honest). :)

--
Shane




More information about the dns-operations mailing list