Re: Transfering a domain

[davidk@ISI.EDU]

Hi Kent,

> Kent Crispin writes :
> 
> After some thought I think the public visibility is quite 
> sufficient.  Remember that the end user will have a digitally signed 
> document that cannot be refuted, as well.

Yes. You could make it completely secure by using a combination of
encryption and authentication but it is probably a good idea to not make
things more complicated then necessary. Security can also make things more
painful to work with. And authentication is more accepted technology then
encryption (in most countries).

> > There is a slight problem here or I didn't understand your last sentence.
> > The repository OR the end-user are the only ones that could (should) add
> > the data to the DNS since the end-user runs primary for its own site and
> > the repository primary for the TLDs.
> 
> Ah -- yes.  I finally see what you were thinking -- it's puzzled me
> for some time.  In your model the key and whois data go in the *users*
> zone.  In my model they go into the *registries* zone, with the glue
> records for the users SLD.  That, incidentally, was why I wasn't so
> worried about accessibility of the contact info as an issue -- if the 
> TLD DNS goes down you have far more serious problems to worry about.

No. I would like to have the whois data in the registrars zone or whois
server. However, I only want data at the registars level that is not
vital for a functioning DNS and transfers of one registrar to another;
that means I would like to have nameserver data, registrar data, end-user
domain (and no end-user public key anymore, see below). Whois data is not
vital, it can easily be recreated by the end-user when a transfer is
done.

I pointed out that there are variants like moving the public key to the
user and/or maintaining the whois data at the end-user *and* registars
premises for additional redundancy. I don't think that is a good idea though.

> No, I am convinced that with a signed certificate from the original 
> registrar the user could always get a change done.

I misunderstood you. The certificate is indeed enough. That means that
our models can now be considered as the same ;-) with some minor
differences at the implementation level (use of DNS or a simple database
as the database, I would like to have a whois style database at the
registrar level and a simple non public database with a dump to DNS at
the repository level)

> Well, of course, I borrowed :-).

Me too ;-).
 
> I agree -- editing of the zone files is for the birds (though that's
> what I did...) This is a perfect application for a small database. 
> Note that it doesn't have to be visible to the outside world, though. 
> 
> In the not too distant future, however, I think that dynamic update 
> in DNS would handle the job perfectly.

I would still prefer to have a disk file when you have a nameserver
failure... Dynamic updates will at least give you an instant domain (if
the 60 wait period gets eliminated ;-))

> Actually, they already did -- recall that I wasn't convinced of the
> viability of using the users' public key.  I now think it is the
> correct approach.  Furthermore, and amazingly enough, it is really
> straightforward to implement -- I probably won't be able to do it 
> this weekend, but by sometime next week I should have it added to my 
> prototype.  The main issue is a resonable interface for scarfing up 
> the users public key.

That is not easiest thing -- Why do you think not everybody is using PGP ;-)

David K.
---