North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNSSEC in public

  • From: Paul Vixie
  • Date: Mon Sep 12 15:08:49 2005

[email protected] ("Dan Mahoney, System Admin") writes:

> In response to a recent question I saw regarding DNSSEC on RIPE domains, 
> I'd like to ask if there's any sort of draft or standard that anyone knows 
> about for doing DNSSEC in the public, using either a "root" key and/or 
> possibly having master keys pulished in WHOIS?

there is no plan i know of involving master keys published by whois.  (that's
sort of a chicken-or-egg approach, since you'd be using dns to figure out what
whois server to ask.)

there are plenty of web sites that talk about the general field of deployment,
most of which are all reachable via jacco's excellent www.dnssec.net web site.
however, your question falls outside of the things most deployment experts are
willing to talk about in public.  since i've had quite enough coffee and maybe
a little extra, i'll see what i can offer.

> I see a very experimental thing Verisign is doing for the .net zone, and 
> also for some other opt-in zone, but I'm sure that's highly experimental 
> at this point.
> 
> I guess my question is: is there even something up for discussion at this 
> point?  I know it's early in the game.

the official plan is, every zone's zonesigning key is signed by that zone's
keysigning key, and that zone's keysigning key is signed by its parent zone's
zonesigning key.  thus, every zone is at the mercy of its parent zone's
deployment schedule, and nothing is really possible until the root zone is
signed, since that will allow the TLD's to sign, which will allow SLD's to
sign, and so on down the tree.

this stuff works in the lab, but there are several pieces still missing:

1. distributing and updating the root zone's keysigning key

        some say, make the key, keep the private part save, publish the
        public part on IETF T-Shirts, and let everybody hardcode it, and
        if we ever have to change it, we're completely screwed.

        some say, delay deployment until we have a secure way to "roll"
        new root keysigning keys out.  this is a protocol change, and will
        have to take into account embedded and rarely-connected devices.

2. figuring out who would be trusted to hold the root zone's keysigning key

        some people distrust ICANN.  others distrust US-DoC.  still others
        distrust ITU, UN, and/or WSIS -- and some people distrust VeriSign.
        and of course, most of those entities don't trust most of the others.

        yet, those entities are largely responsible for the root zone today,
        and they have to learn to increase their mutual trust as well as
        their collective perceived trustworthiness, or there will be no
        DNSSEC deployment at the root zone level.

one candidate-conclusion that leaps to mind is "this can't ever work".  more
charitibly, one might say that "it's not anywhere close to being deployable."

my own views are: (1) hardcode the root zone keysigning key, and hope
there's an in-band key-rollover protocol ready to roll out before the first
time we have to invalidate/replace/revoke this key; and (2) use DLV to get
deployment started, and hope that the root zone and the most compelling TLD's
are all signed before DLV reaches its built in crippleware scaling limit.

now for the disclaimers.  i work at ISC, and we've been funded to work on
DNSSEC for most of the last ten years.  our BIND9 (9.3.x and soon 9.4.x) is
as far as we know a complete implementation of the current (DNSSEC-bis) spec.
it's free software, free as in BSD-style license.  we don't make money from
your use of our software, and when we do collect money (usually from support
or software development), we're a non-profit corp with no shareholders so we
can only spend our money on public benefit activities.

oh, and one more thing: i'm the primary pusher behind DLV.  DLV is the
thing you're alluding to when you talk about the .NET experiment at
VeriSign.  DLV isn't experimental, ISC is going to run it as a full
production service as a way to get dnssec deployment to begin even though
there are a lot of things not quite ready yet.  you can learn more about DLV
at: <http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00807.html>.

i hope this helps.  and do remember to look at jacco's www.dnssec.net pages;
he (wisely) does not delve into the root zone's political problems or the DLV
controversy, but otherwise his site is a very complete and useful reference.
-- 
Paul Vixie