[dnssec-deployment] dot MUSEUM implemented DNSSEC

Andrew Sullivan ajs at commandprompt.com
Mon Sep 22 11:36:16 EDT 2008


On Mon, Sep 22, 2008 at 07:20:10AM -0700, Patrik Fältström wrote:

> 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.

This is true, but you can do something similar with key records.
There's nothing that says you can't have more than one DS in the
parent, corresponding to more than one key in the child.  And the RFCs
as currently written require every one to be tried until one succeeds
or they're all used up.

Of course,

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

if what you're saying is that the parent has more than one NS server
and one of them is broken, then the client will go to others; whereas
if the client gets an answer that causes a BOGUS evaluation via one of
the paths, you get an early failure.  But that's not a perfectly good
analogy.  The analogy that's apt is that you have more than one name
server in the delegation chain, and you forget to update one of your
name servers when you add newservice.example.org.  In that case, all
queries getting to that one non-updated name server for
newservice.example.org will get Name Error instead of the answer they
should have.

What I think people are thinking of are the "lameness" cases that are
mostly solved by caches and such like.  These are the ones that turn
out to be undetectable for weeks at a time, because there's enough
data getting promoted from the additional section that you get glue
you can use.  I expect that, as various DNS servers are improved to deal
with forgery problems, many of those formerly-working lame cases will
break anyway.  

The DNS is remarkably robust in the face of administrator error, but
this turns out to have a lot of nasty side-effects for security.
We're going to have to give up some of that robustness if we're going
to rely on the answers, it turns out.

A


-- 
Andrew Sullivan
ajs at commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/



More information about the Dnssec-deployment mailing list