[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Kent Crispin <kent@songbird.com>, Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
cc: ietf-provreg@cafax.se
From: Catherine Murphy <cathym@arin.net>
Date: Thu, 8 Feb 2001 10:57:18 -0500 (EST)
In-Reply-To: <200102062113.f16LDEt02026@nic-naa.net>
Reply-To: Catherine Murphy <cathym@arin.net>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Nameserver as object/entity or not ?


I'd like to chime in. Both Eric and Kent state the problem well: 

Eric Brunner-Williams in Portland Maine wrote:

> Making nameservers into first class objects isn't a given, as
> the dependency relationship between nameservers objects and domain objects
> mandates a contention mechanism.

Kent Crispin wrote:

> If you have nameserver objects, then you have in effect created
> potentially conflicting ownership/authentication domains, and this
> seems to me a very fundamental problem.  (That is, a domain can be 
"owned"
> by A, while the nameservers for the domain may be owned by "B".)  If
> only domains can be owned objects, then there are no possible conflicts
> (at least in the registry DB).

If the GRRP is to be used for something other than domain name
registration down the road, e.g., IP address registration, the protocol
should leave this characterization aside. 

IP registries are a case in point. While I can see where some domain
registries will want to treat nameservers as objects, we can not. The
nameserver information that ARIN receives for in-addr nameservers is an
attribute (or dependent object) of the IP network object. Kent's point of
potentially conflicting ownership/authentication would also hold true for
us. Since we are receiving the information from a particular network
registrant, the nameserver information only extends to the scope of his
authority, i.e., that network. The same nameservers could quite possibly
be listed for other networks, but the authority to change a nameserver is
limited. There is not inherent "ownership" of the nameserver information.
If both Network A and Network B list ns1.foobar.net as its in-addr
nameserver, Network A could not come to us and say, change all instances
of ns1.foobar.net to ns2.foobar.net. Rather, it could only affect that
change against its network; ns1.foobar.net would remain on network B.

We also differ in that we will be tracking no other data about the
nameserver except for the nameserver itself, e.g., ns1.foobar.net.
(Currently, we receive the IP address of the nameserver, which is
displayed in whois, but is not used to produce glue records. Since we are
not authoritative for these nameservers, it does not make sense for us to
maintain the IP address.) 

Cathy

---------------------------------------------
Cathy Murphy <cathym@arin.net>
Principal Software Engineer
American Registry for Internet Numbers (ARIN)
+1 703 227 9875



Home | Date list | Subject list