On 2000/08/29, Hollenbeck, Scott wrote:
> Eric,
>
> Thanks for the clarification.
>
> I don't like the idea of severing the relationship between a name server and
> the server's parent domain when the registry is authoritative for the
> server's and domain's TLD. I can see some ugly situations where one
> registrar is responsible for example.com and another is responsible for
> ns1.example.com. If example.com needs to be deleted by one registrar what
> happens to ns1.example.com, whose registrar might not want to cooperate?
But on the other hand, this is quite ugly too:
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.
The point is, if a domain name is available, any registrar should be able to
register it.
> However, name servers whose parent domain is in a non-authoritative TLD do
> present some interesting issues as you describe below. Let me think about
> those for a bit.
>
> Scott Hollenbeck
> Network Solutions, Inc. Registry
>
> -----Original Message-----
> From: Eric Schaetzlein [mailto:eric@schlund.de]
> Sent: Tuesday, August 29, 2000 9:27 AM
> To: Hollenbeck, Scott
> Cc: rrp@nsiregistry.com
> Subject: Re: [NSI-RRP] FW: I-D ACTION:draft-hollenbeck-grrp-reqs-03.txt
>
>
> 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.
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 - 11:16:36 EDT