Eric,
Thanks for taking the time to provide your comments. I'll address them
below.
Scott Hollenbeck
Network Solutions, Inc. Registry
-----Original Message-----
From: Eric Schaetzlein [mailto:eric@schlund.de]
Sent: Friday, August 25, 2000 5:34 PM
To: shollenb@netsol.com
Cc: rrp@nsiregistry.com
Subject: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt
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])
[SAH] I agree, and I've changed the text for requirement five as follows:
"This means that IP address(es) for name servers whose parent domain exists
in another TLD SHOULD be registered only in the registry that is
authoritative for the TLD of the name server."
to
"This means that IP address(es) for name servers whose parent domain exists
in another TLD MUST be registered only in the registry that is authoritative
for the TLD of the name server.".
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?
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.
This archive was generated by hypermail 2b29 : Mon Aug 28 2000 - 09:27:42 EDT