[dnssec-deployment] dot MUSEUM implemented DNSSEC

Patrik Fältström patrik at frobbit.se
Mon Sep 22 10:20:10 EDT 2008


On 22 sep 2008, at 07.16, Andrew Sullivan wrote:

> On Mon, Sep 22, 2008 at 09:19:08AM +0200,  
> Mats.Dufberg at teliasonera.com wrote:
>
>>> Surely this is no different than the current care needed when  
>>> updating
>>> NS records at the parent side of the zone cut, is it?
>>
>> DNSsec creates a tighter chain. We have to make sure that  
>> redelegation
>> is not the weakest link. -- Yes, it is the same process but DNSsec
>> requires higher degree of safety when it comes to the redelegation  
>> part.
>
> I don't see how this is true.  If the parent side of the zone cut has
> the wrong data, then queries will end up at the wrong server.

True, but the failure normal scenario is that you get a lame  
delegation. You then have, as Olaf explains, as many bullets in your  
canon as you have NS records. As long as one "works", the client will  
get data back.

With DNSSEC, you have only one "trust delegation" and if that is bad,  
things are really bad.

So to some degree, things are more fragile with DNSSEC than without.

That said, I think personally for the security reasons you lay out we  
have today far too relaxed requirements on "correct operations" of the  
DNS, and the "almost works, but sometimes fails" scenarios are too  
many. Sometimes it is better if things just break when they are broken.

    Patrik

>  That
> server could easily just not be answering for the zone, or not turned
> on, or not running a DNS server, or whatever.  In any case, it's
> certainly not pointing to the "real" authoritative server.  So the
> client gets bad data.
>
> In a DNSSEC scenario, the effect of "client gets bad data" might well
> be (of course) that the client marks the zone bogus and the site goes
> dark for that client.  If you are suggesting that "client thinks site
> is bogus" is somehow worse than "client gets the wrong answer", then I
> suggest the zone is a poor candidate for DNSSEC in the first place.
> After all, if it's ok that the client gets the wrong answer, there's
> no reason to put wrong-answer-detection into the chain.
>
> A
>
> -- 
> Andrew Sullivan
> ajs at commandprompt.com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
>
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <dnssec-deployment at shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-off at shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/Lists/dnssec-deployment/ 
> >
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
>




More information about the Dnssec-deployment mailing list