On 2000/08/28, Hollenbeck, Scott wrote:
> Second, in a thin Registry model, registering nameservers as a separate
> entity "owned" by a single
> Registrar creates types of situations that may make it impossible to
> successfully register a domain name.
>
> [SAH] Yes, I understand this problem. Is there a specific section of the
> document that presents a problem with the scenario you describe below?
[ES] Yes, there are actually many sections.
The concept of nameservers being separate objects spreads through the whole gRRP.
(3.4 [4] [5] 3.5 [2] [4] etc.)
There are two alternatives in my opinion:
a) let everyone register nameservers (give up that parent domain stuff)
and introduce nameserver transfer procedure (which makes sense when
nameservers are a separate objects owner by one registrar)
Right now, in NSI-RRP and gRRP, a ccTLD-based nameserver once registered
will *always* belong to one registrar. This can't be true.
As a real example, our own ns3.schlund.de belongs to NSI Registrar and since
it is referenced by zillions of domains, we will never be able to switch it over
to Schlund Registrar unless a transfer procedure is envisioned.
b) Integrate the concept of a "slim" registry (nameservers are attributes of
domain objects, not separate objects)
This requires substantial revision of the current gRRP, but as mentioned before,
this solves a whole amount of problems* and is current practice in most ccTLD Registries.
[* 1. Dead End Problem, 2. NS-Hijacking, 3. Chicken-Egg Problem, see below]
> This problem will always arise when objects shared by multiple Registrars
> are maintained by
> only one Registrar (refer the discussions on ISP-maintained person objects
> in the
> RIPE database)
>
> Let me explain this in detail:
> Registering nameservers in a thick Registry makes sense because you can
> store contact information with
> the nameserver (zone contact/zone-c).
>
> So all there is left of the nameserver object in a thin Registry is
> - the nameserver's domain name
> - IP addresses, which are not necessary unless they serve as glue records,
> that is
> parent_domain_of(nameserver) = domain_nameserver_is_used_in
> &&
> registry_is_authoritative_for(tld_of(nameserver)) = yes
> - a Registrar maintaining that object
>
> So the actual algorithm for a Registrar Y to register a given domain
> described as
> (domain, ns1, ns2, ns3, ...)
> is:
>
> foreach ns in (ns1, ns2, ns3, ...)
> if is_registered(ns)
> then
> next
> else
> if registrar_of_domain(parent_domain_of(ns)) = Y
> then
> register_nameserver(ns)
> next
> else
> fail
> # can't register_nameserver(ns) because lack of
> authority
> endif
> endif
>
> endforeach
> register_domain(domain)
>
> This might actually really happen, given the following example:
> Registrar X Registrar Y
> |- company.tld |- subsidiary.tld
>
> The mothercompany registers with Registrar X.
> The subsidiary registers with Registrar Y.
> Registrar Y is to register (product.tld, ns1.subsidiary.company.tld,
> ns1.subsidiary.tld)
> This fails, even if product.tld is available.
>
> These are the three situations related to nameserver objects:
> 1. Dead End Problem
> A Registrar can't register a domain name because he would have to
> register a nameserver
> first whose parent domain is registered with another Registrar.
>
> 2. NS-Hijacking
> Register your competitor's nameserver with your IP address before he
> does it,
> using the Registrar of the competitor's domain.
>
> Register any ccTLD nameserver with your IP address.
>
> 3. Chicken-Egg Problem
> Image you want to register foo.tld with nameserver ns.foo.tld.
> You can't register foo.tld because the nameserver is not yet
> registered, but you
> can't register the nameserver ns.foo.tld because the parent domain
> is not yet registered.
> In fact, the only possible solution in the current model is to first
> register foo.tld
> *without* nameserver (something that should not be made possible),
> then register the nameserver,
> and finally *modify* the nameservers of a domain.
>
>
>
> You should consider a type of "slim" Registry where there are only domain
> objects
> and nameservers (and their glue IP addresses, only where needed) are just
> attributes of the domain name.
>
> The slim Registry is in use in many ccTLDs and eliminates the problems 1-3.
>
> Last, it makes sense to query domain names that are associated with another
> Registrar,
> mostly because you should then get at least the same amount of information
> that can be obtained
> by querying the whois. (section 3.11 [4])
>
> [SAH] I agree, and that's why the text in this sections says "Requests to
> retrieve information describing a registered object MAY be limited to the
> registrar that currently sponsors the registered object" instead of "MUST be
> limited. Using MAY allows the protocol to provide this feature if the
> registry environment requires it, and it also allows the registry to not
> allow such queries. I know that ICANN has requirements for information
> access via whois, but not all registries are supporting ICANN at this moment
> so I thought it best to provide some flexibility here.
> ---------
> See http://www.nsiregistry.com/maillist/rrp/
> for message archives and subscription management information.
Mit freundlichen Gruessen
Eric Schaetzlein
-- Eric Schaetzlein Schlund + Partner AG Tel: +49 721 91374 50 Leiter Domain Services Erbprinzenstr. 4-12 Fax: +49 721 91374 20 D-76133 Karlsruhe Mail: eric@schlund.de--------- See http://www.nsiregistry.com/maillist/rrp/ for message archives and subscription management information.
This archive was generated by hypermail 2b29 : Tue Aug 29 2000 - 09:28:37 EDT