Re: hat tip to .gov hostmasters

* David Conrad · * Mon Sep 22 13:16:16 2008

On Sep 22, 2008, at 8:11 AM, Keith Medcalf wrote:

Correct, you need a validating, security-aware stub resolver, or the
ISP needs to validate the records for you.

That would defeat the entire purpose of using DNSSEC. In order for
DNSSEC to actually provide any improvement in security whatsoever,
the ROOT ZONE (.) needs to be signed, and every delegation up the
chain needs to be signed.

The root does not need to be signed to provide security improvement.
If you have configured the (say) .SE trust anchor in your validating
resolver, you greatly reduce the chances that any lookup for a name
in .SE can be spoofed. The downside of not having the root signed is
that you need to maintain multiple trust anchors.
And EVERY resolver (whether recursive or local on host) needs to
understand and enforce DNSSEC.

I personally believe it is more-or-less safe to trust communications
local to the machine. As such, running a validating resolver on your
local host would suffice. Having a stub resolver also validate in
this scenario would be overkill.
If even one delegation is unsigned or even one resolver does not
enforce DNSSEC, then, from an actual security perspective, you will
be far worse off than you are now.

In what way? I'm running a validating resolver on my laptop (using
the signed root zone and trust anchor available from ns.iana.org so I
only have to deal with one trust anchor). If someone tries to spoof a
name in the root, .SE, .BG, .PR, .BR, .CZ, their efforts will fail.
How is this worse off than before I configured my resolver?
Until such time as EVERY SINGLE DOMAIN including the root is signed
and every single DNS Server and resolver (including the local host
resolvers) understand and enforce DNSSEC you should realize that
DNSSEC does nothing for you whatsoever except give the uneducated a
false sense of "security".

If this were true, DNSSEC would be a complete waste of time.
Fortunately, it isn't true.
Regards,
-drc