http://it.slashdot.org/article.pl?sid=08/09/22/1253201&from=rss
nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)).
/sf
nice to see a wholesale DNSSEC rollout underway (I must confess to being a
little surprised at the source, too!). Granted, it's a much more manageable
problem set than, say, .com - but if one US-controlled TLD can do it, hope
is buoyed for a .com rollout sooner rather than later (although probably not
much sooner :)).
I'm not much up on DNSSEC, but don't you need to be using a resolver
that recognizes DNSSEC in order for this to be useful?
* Jason Frisvold:
You do -- and last time I checked few native resolvers actually did :
glibc doesn't, and I'd be surprised if the Windows resolver does
Simon
Chicken, meet egg.
I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things.
Chris
Florian Weimer wrote:
* Jason Frisvold:
nice to see a wholesale DNSSEC rollout underway (I must confess to being a
little surprised at the source, too!). Granted, it's a much more manageable
problem set than, say, .com - but if one US-controlled TLD can do it, hope
is buoyed for a .com rollout sooner rather than later (although probably not
much sooner :)).I'm not much up on DNSSEC, but don't you need to be using a resolver
that recognizes DNSSEC in order for this to be useful?Correct, you need a validating, security-aware stub resolver, or the
ISP needs to validate the records for you.
In public space like .com, don't you need some kind of central
trustworthy CA?
* Colin Alston:
Correct, you need a validating, security-aware stub resolver, or the
ISP needs to validate the records for you.
In public space like .com, don't you need some kind of central
trustworthy CA?
No, why would you? You need to trust the zone operator, and you need
some trustworthy channel to exchange trust anchors at one point in
time (a significant improvement compared to classic DNS, where you
need a trustworthy channel all the time).
I totally agree on that, but wanted to point out that there still is
some work be done.
The folks at NLnet do have a nice DNSSEC implementation, though, as
well as the BIND library.
Simon
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. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
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.
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".
It is likely that IPv48 will be deployed long before DNSSEC is implemented.
* Simon Vallet:
I'm not much up on DNSSEC, but don't you need to be using a resolver
that recognizes DNSSEC in order for this to be useful?You do -- and last time I checked few native resolvers actually did :
glibc doesn't, and I'd be surprised if the Windows resolver does
Windows doesn't. To my knowledge, there aren't any deployed
valdiating, security-aware stub resolvers. Your best bet is to run
BIND or Unbound locally with appropriate trust anchors, and use that
as the system's resolver. With modern LRU-based caches which are
efficient even at smallish sizes, this isn't much of a problem.
Chicken, meet egg.
I think the point of the original post is that one end or the other has to
start things. At least we have one US zone doing something on the server
end of things.
Oh, agreed, absolutely. And it's great to see. However, neither the
slashdot blurb, nor the NetworkWorld article mention that without a
valid resolver, there is no guarantee of security. Sure, they mention
that vendors are rolling it out and that ISPs should be following
suit, but no mention is made of the end-user's resolver at all...
DNSSEC is not a PKI. There are no CAs and no X.509 certificates. It's a chain of trust that can be validated using public/private key pairs. OK, that's oversimplification but you get the idea.
While we wait for applications to become DNSSEC-aware, if your local DNS server can be trusted (a big "if" of course) then it can proxy the DNSSEC awareness for you. Since nearly everybody trusts a local DNS server to resolve queries, then making that server DNSSEC aware is an enormous step forward, even if the actual applications and operating systems on end-user computers are not fully DNSSEC-aware and won't be for many years to come.
Marc
yes and no. to fully trust the data from the servers you need
three things:
) signed data (this is what .gov is doing)
) a validator in the end system (this is mostly missing/not configured today)
) accurate trust anchors from a couple of places in the DNS namespace ##
however,
if all you start with is signed data - it becomes possible to verify the
source of the data - independently of inline DNS validation. e.g. you
can - with a high degree of certainty, be assured that the root zone you
load is really the ORSN root and not that flaky root from DoC/ICANN/VSGN... 
so "naked" signed data, in the absence of TA's or validators is still
useful.
## you'll need a couple of these - and how you get them and keep them up to date is
still a mostly unsolved operational problem.
--bill
* Keith Medcalf:
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. And EVERY resolver (whether recursive or
local on host) needs to understand and enforce DNSSEC.
Either the resolver needs to enforce, or the host. It's not necessary
to do both. It's also not strictly necessary that the root is signed,
provided that there is some way to manage the trust anchors (either
through software updates, like it is done for the browser CA list, or
through regular DNS management at the ISP resolver).
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.
Why?
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".
DNSSEC is totally invisible to the end user. There won't be any
browser icon that says "it's okay to enter your PII here because the
zone is DNSSEC-signed". It's purely an infrastructure measure, like
physically securing your routers.
* marcus sachs:
While we wait for applications to become DNSSEC-aware,
Uhm, applications shouldn't be DNSSEC-aware. Down that road lies
madness. What should an end user do when the browser tells him,
"Warning: Could not validate DNSSEC signature on www.example.com,
signature has expired. Continue to connect?"
> 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. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC.
er, no. the root zone does not need to be signed and not every delegation.
and only the resolvers in the path from auth servers to validators need to
ensure that the DNSSEC data is retained.
if the only TA I have is for .SE (configured in my validator) and my resolver
passes the DNSSEC data unchanged it received from the .SE servers, then I can
securely trust the (short) validation chain when I look up axfr.se.
even though -nothing else- is signed.
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.
depends on your POV of course...
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".
I think you have unrealistic expectations. Time will tell.
It is likely that IPv48 will be deployed long before DNSSEC is implemented.
--bill
actually, I am really hoping that at least one API
is standardized so that applications can use DNSSEC
data. We never finished the discussion on fail/open
fail/closed wrt DNSSEC.
--bill
nice to see a wholesale DNSSEC rollout underway (I must confess to
being a little surprised at the source, too!). Granted, it's a much
more manageable problem set than, say, .com - but if one US-controlled
TLD can do it, hope is buoyed for a .com rollout sooner rather than
later (although probably not much sooner :)).
It ain't done yet.
I don't speak for the hostmasters of .gov or any subdomain thereof.
But I'll believe it when I see it.
Remember, they've also "mandated" IPv6 support on all backbones.
Jason Frisvold wrote:
Chicken, meet egg.
I think the point of the original post is that one end or the other has to
start things. At least we have one US zone doing something on the server
end of things.
Oh, agreed, absolutely. And it's great to see. However, neither the
slashdot blurb, nor the NetworkWorld article mention that without a
valid resolver, there is no guarantee of security. Sure, they mention
that vendors are rolling it out and that ISPs should be following
suit, but no mention is made of the end-user's resolver at all...
I dunno, a few very strategically placed validating resolvers could subject
a huge amount of DNS traffic to a much higher bar were the senders so
inclined to sign their zones. But I tend to view these kinds of things much
more from an "epidemiology" point of view: you don't have to have 100%
eradication to control an epidemic. Same thing pretty much goes with internet
based attacks, IMO: when the barrier is set sufficiently high in one area,
attackers don't spend their entire time trying to break that barrier, they find the
next lowest barrier and move on.
Mike
the NetworkWorld article (in the printer-friendly version, at least)
has a little table that shows the DNSSEC status of the major vendors.
And support in the resolver library is not strictly necessary, as long
as you trust _your_ (or your ISP's) nameservers.
(not to say that it isn't a good idea, just that it's not requirement
for initial rollout.)