[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: what should be COREdb contain (was: Re: Anti Capitalism?)



David,

The info for the Name Servers has to stay in the back end regestrie.
If it is distributed the you would have to either send update
notifications to the central regestry, or all front end regestries
would have to be contacted to get all the name server info for
building a zone table. If this were to accur each night with 3K
front end regestries I doubt it would scale well.

If the contact info were distributed it would have to be done
in such a way that it was interoable from front end regestrie
to regestrie. Implementing a Gardian System where all objects
were garded by regestries that couldn't be trusted could become a
problem. Unless we don't require the CORE-db to implement garded objects.

If I want to regestter a domain and list a set of name servers, the contact
of each one of those name servers must be sent an ack/nak request. I would
have to look up each one of those contacts in a possibly untrsted regestrie.
I doubt that if you distribute contact data that a Gardian system could
be developed. Unless you could trust each regestry to maintain its objects,
and allow other regestries to interface to their database.

This is I believe, one of the problems RIDE is working on. Have we
gotten far enough that we could implement such a system?

-Rick




On Jan 3,  3:45pm, davidk@ISI.EDU wrote:
> Subject: Re: what should be COREdb contain (was: Re: Anti Capitalism?)
>
> Rick,
>
> > Rick H. Wesson writes :
> >
> > What do you suggest that the COREdb contain. Only pointers to the
> > Name Servers?
> >
> > Domain: Foo.Bar.
> > NS1: NS12-HST@Reg1
> > NS2: NS135-HST@reg3
> >
> > Or should it only have Domain Foo.com lives at Regestrie #1.
>
> >From my previous mail:
>
> In the domain name class:
>
> - domainname
> - pointer to registrar that registered the data
> - DNS configuration data (nameservers)
> - public keys of the domain holder (needed for transfer of
>   domain registration services between registrars)
>
> In the registrar class (note there are much less registrars then domains):
>
> - all contact information of the registrar
> - public keys of registrars
>
> The DNS configuration data could also be moved to the registrar, but I
> consider that too risky since the repository should stay valid even if a
> registrar goes out of business.
>
> David K.
> ---
>
>-- End of excerpt from davidk@ISI.EDU



-- 
Rick H. Wesson