DNSSEC - does it exist?

[Matt Larson]

Hello, Chris, everyone.

On Mon, 23 Oct 2006, Chris Drake wrote:
> DNSSEC has been mentioned a few times.  It seems to be a way for
> authoritative servers to digitally sign DNS replies - with the intent
> that client resolvers check signatures - including (as far as I can
> tell) the whole chain up to the "root" zone.
> 
> What I can't find is any obvious mention of who the root is, nor how
> I'd get my keys "signed" by them, nor how a client resolver (eg: a
> potential victims Windows XP box) might install a root key - which
> leads me to believe there's no DNSSEC root authorities yet, and thus
> this protocol doesn't exist.
> 
> Am I wrong?  (I hope so!!! - and if I am - where/how do I submit my
> DNSSEC CSR? - this is a really cool idea)

My VeriSign colleagues on this list pointed me to this thread and I
wanted to chime in with the status of DNSSEC.

The good news is that the DNSSEC specification is finished and
published: see RFCs 4033, 4034 and 4035.  It took us in the IETF DNS
community an embarrassingly long time to get a protocol that's
operationally deployable, but it's done.  (OK, almost done.  There is
a late-breaking protocol add-on called NSEC3 that adds two features
needed by the largest top-level domain registries; the principal
supporters are the registries for .com, .net, .uk and .de.  Gory
details at
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3/draft-ietf-dnsext-nsec3-07.txt.)

The bad news is that deployment is going to take a while.  Software
support is minimal right now: only the very latest versions of BIND,
for example (versions 9.3 and higher), support the latest version of
DNSSEC specified in RFCs 403[345].  (I am pleased to report, however,
the VeriSign contributed heavily to the Unbound DNS resolver, which
does support DNSSEC; see http://www.rfc.se/unbound/.)

There are no certificates in DNSSEC.  Instead, the trust model follows
the DNS delegation path.  Zones have public/private key pairs and your
zone's parent zone vouches for your zone's key by signing it.  DNSSEC
validation requires one or more keys as trusted starting points for
validation, referred to in this context as "trust anchors".  In a
perfect world, the DNS root zone will be signed and trust will flow
downward, requiring DNSSEC validators to need only one trust anchor
configured.  The real world is likely to be murkier, with both
political and technical issues delaying signing the root zone.
(Contrary to an assertion earlier in this thread, there is no
squabbling between VeriSign and the United States Department of
Commerce delaying root zone signing.)

As significant zones get signed, DNSSEC validators will need to be
configured with these zones' trust anchors until the root zone is
signed.  There is already one DNSSEC-signed TLD zone: Sweden's .se.
Other TLDs have indicated interest in signing their zones.  I can't
speak for them, but I can say that VeriSign hopes to sign .tv (which
we run under contract to the government of Tuvalu) some time in 2007
with .com and .net following soon after.  (These plans are subject to
change based on engineering resource availability and we absolutely
require the NSEC3 extensions I mentined above to sign .com and .net.)

Someone mentioned DNSSEC look-aside validation (DLV) as a possible
alternative to getting key infrastructure zones (like the root and
.com) signed.  DLV is indeed a possible alternative, but has its own
set of issues.  It's one vendor's off-the-standards-track proposal for
a different DNSSEC trust model.  There is not widespread support for
it in software yet, either, nor are there any fully up-and-running DLV
registries yet.

I've subscribed to this list and would be happy to address follow-up
questions here or off list.

Matt
--
Matt Larson <mlarson at verisign.com>
Director, DNS Research
Advanced Products and Research Group, VeriSign, Inc.