RE: [NSI-RRP] Name Server Transfers

From: Hollenbeck, Scott (shollenb@netsol.com)
Date: Mon Sep 11 2000 - 08:18:59 EDT

  • Next message: Eric Schaetzlein: "Re: [NSI-RRP] Name Server Transfers"

    Eric,

    I responded to your comment about using name servers as attributes of
    domains last week. If every domain has it's own copy of a server name and
    IP address as an attribute, how would you propose managing a server IP
    address or name change? If I understand correctly, the model you're
    suggesting would require one-by-one modification of every domain that uses
    the server in question -- potentially many thousands of domains in a TLD
    like .com. The model I'm suggesting would require a change to one object --
    the server itself. If you see this differently, please explain how such a
    change could be made managed easily.

    I don't see anything in the current grrp draft that discriminates between
    thick or thin models using the definitions of "thick registry" and "thin
    registry" as presented in the draft. As I explained last week when you
    raised these same points, I don't see the problems you've described below in
    a registry environment that is shared by multiple registrars.

    Scott Hollenbeck
    VeriSign Global Registry Services

    -----Original Message-----
    From: Eric Schaetzlein [mailto:eric@schlund.de]
    Sent: Monday, September 11, 2000 7:48 AM
    To: Hollenbeck, Scott
    Cc: 'NSI RRP Mailing List'
    Subject: 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:25:43 EDT