Re: [NSI-RRP] Name Server Transfers

From: Eric Schaetzlein (eric@schlund.de)
Date: Mon Sep 11 2000 - 07:48:24 EDT

  • Next message: Hollenbeck, Scott: "RE: [NSI-RRP] Name Server Transfers"

    Hi Scott,

    you are absolutely right - if we are talking about a thin registry and a exTLD nameserver
    (exTLD nameserver = nameserver name in a TLD not sponsored by the registry).

    Because then, the nameserver object is nothing more than its primary key, the nameserver name.
    (given the last change to your gRRP, that a exTLD nameserver MUST NOT contain IP addresses)

    In all other cases, that is thick registry (nameserver contains zone-c data) or a
    inTLD nameserver (nameserver contains IP addresses) you have an object ownership issue.

    That ownership issue can be solved in many different ways,
    but the parent domain ownership model creates loops, deadlocks and
    inter-registrar dependencies:

    1. can't register nameserver ns.xyz.tld because xyz.tld isn't registered -
       can't register xyz.tld because ns.xyz.tld is its nameserver.

    2. registrar Y can't register abc.tld because its nameserver is ns.uvw.tld,
            but ns.uvw.tld is unregistered and uvw.tld is owned by registrar X.

    Now if you go out in the real world and try to find a model that matches best reality,
    you'll notice that nameservers are objects shared by multiple registrars but really
    "owned" by the zone-c. But there is not zone-c in a thin registry.

    So the only reason to create nameservers objects as separate entities in a registry
    would be glue records. But glue records are a parameter of (domain, nameserver).
    You'll never need 90% of all IP addresses in the registry.

    Very rough, it would be like:
    domain: xyz.tld
    nserver: ns.xyz.tld 11.22.33.44
    nserver: ns.uvw.tld
    nserver: ns.aaa.de

    ns.xyz.tld needs only a glue record (IN A 11.22.33.44)
    when used as a nameserver for xyz.tld

    So, final conclusion, I think the model where nameserver names
    are attributes of domains together with an where-required glue record
    solves a lot of problems. It has been in use in most ccTLD registries
    and therefore been proven as a working model.

    I understand this means substantial changes to the current gRRP,
    but a generic RRP which does not consider the protocols that more than
    200 registries are currently using but rather relies on one special
    RRP (the NSI RRP) model can not be called really "generic" (IMHO).

    Best regards,

    Eric 

    --
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

    On 2000/09/07, Hollenbeck, Scott wrote:
> I'd like to close on a thought first raised by Eric Schaetzlein regarding
> name server transfers.  Last week we discussed allowing registrar transfers
> for name servers used in a TLD for which a registry is not authoritative.
> Having had some time to think about it, I'm not sure that there's much value
> in doing this.  Here's why:
> 
> The registry that publishes the zone file containing A records for a server
> controls the association between the server name and IP addresses that
> appears in the zone.  If the name or addresses changes, that can be handled
> within the authoritative registry.
> 
> Another registry that uses this name server for domains in another TLD SHALL
> NOT publish an A record for this server.  There's no "ownership" of this
> server in this registry, but the registry will publish an NS record for the
> domain(s) served by the server.  All this registry needs to know is the name
> of the server, which MAY need to be changed if/when a change is made in the
> authoritative registry.  This change can be done by whichever registrar
> initially added the server to the registry.  A registrar transfer would do
> nothing more than change the registrar capable of changing the name or
> deleting the server, and I'm not sure there's any real value in this since
> the real control still resides within the authoritative registry.
> 
> If anyone disagrees, please explain where you see value in such a change of
> administrative control.
> 
> Scott Hollenbeck
> Network Solutions, Inc. Registry
> ---------
> See http://www.nsiregistry.com/maillist/rrp/
> for message archives and subscription management information.

    ---------
See http://www.nsiregistry.com/maillist/rrp/
for message archives and subscription management information.

    This archive was generated by hypermail 2b29 : Mon Sep 11 2000 - 08:18:39 EDT