|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: wrt joao damas' DLV talk on wednesday
On Tue, 13 Jun 2006, Randy Bush wrote: <snip> along these lines - there seem to be a huge number of smallishhow 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? 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: http://www.dnssec-deployment.org./ http://www.dnssec.net/software http://www.ripe.net/disi/dnssec_howto/ http://www.dnssec-tools.org/ 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? http://www.dnssec-tools.org/docs/step-by-step-dnssec-tools/sbs-dt.pdf similarly, how do i enroll psg.com 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 psg.com? andanyone whose registrar won't play, will have to follow the procedure outlined on www.isc.org/ops/dlv/, which involves much manual labour, but can be done. (see http://www.isc.org/ops/dlv/#how_register 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. randy -- Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774
|