Hi Scott,
let me add a couple of comments to the current version of the gRRP draft.
First, an IP address must not be registered when registering a nameserver whose domain name
is outside the TLD the Registry is operating.
Since the Registry is not authoritative for that nameserver's TLD, this creates a potential
source of inconsistencies. Even if a given IP will not be included in the zone file, it is in
the Registry database and that doesn't make sense.
(section 3.4 [5])
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.
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])
Best regards,
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 : Fri Aug 25 2000 - 17:35:13 EDT