North American Network Operators Group

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

Re: wrt joao damas' DLV talk on wednesday

  • From: Lucy E. Lynch
  • Date: Wed Jun 14 11:00:55 2006

On Tue, 13 Jun 2006, Randy Bush wrote:


how about cctlds, which are of great interest to me?  i suspect
that iana will not play, so how would cctlds play in way in which i
can bet my bippies?

and how it would be rolled would be of interest.
key-roll through DLV is no different, from the high level, that
key roll through non-DLV.  either way you have to instantiate a
new key and get it to your registry somehow (either through your
registrar or otherwise) before you start using it.
how do i enroll NG in a way that third parties can reasonably know
is trustable?  from the policy and process pov, how will we move it
to a new zone set and server set when i get rid of it?
along these lines - there seem to be a huge number of smallish
tools related to DNSSEC, but I don't find anything that looks
like a package with a couple of tools and scripts that would be
usable by a small ccTLD - recommendations and good written
exercises that step a newbie through the process would be
very useful - any pointers? I've already looked at:

lots of info - but a cheat sheet and some recommendations for basic tools are needed to get this deployed and used.

is this the current state-of-the-art?

similarly, how do i enroll in a way third parties can
trust?  how do we handshake in a clearly documented process- and
key-wise exchange that gives third parties reason to be confident
in the validity of the key isc hands out for


anyone whose registrar won't play, will have to follow the
procedure outlined on, which involves much
manual labour, but can be done.  (see in particular.)
says not much about how things will actually be verified.  only
that isc will vet, i will fly, ...  heck, for an org, it does not
even state that corp docs of the flavors rirs use for transfers
will be needed/used.

i suspect that where we may be differing, other than restaurant
lore, is that you may be saying "the underlying technology is
documented, and isc are good folk and if we say it's vetted you can
trust us."  problem is that, though i may want to trust isc (heck,
i run isc's code!), for a security exercise, i should not.  an
example of some rigor in policy and process needs to be set.


Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch		(541) 346-1774