Re: Nameserver as object/entity or not ?

["Jordyn A. Buchanan" <jordyn@register.com>]

At 10:57 AM 2/8/2001 -0500, Catherine Murphy wrote:

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

I think that there are two separate issues here:

1) Should name servers be treated as objects or as attributes of other objects?

2) If nameservers are objects, how do we manage ownership of these objects?

Issue #2 seems to me to be mostly a matter of registry policy.  Some 
registries may want to say that the owner of a domain implicitly owns all 
nameservers within that domain.  Others may not, but may want to verify 
that the owner of the domain approves of someone else having a nameserver 
in their domain.  Others may not care at all.  The requirement should be 
for an approach that accommodates these various policies.

If we look at our objects as being "pointers to nameservers" with the 
possibility of multiple pointers to the same actual nameserver, I think we 
can achieve a solution that achieves many of the benefits of the 
nameserver-as-object approach without the inherent ownership issue.  Such 
an approach allows a registrant to use a common name server object across 
many domains (or IP blocks), but doesn't imply that the registrant "owns" 
the name server or that changes made to the object changes the name server 
for other people.

For example, both BigISP and SmallCo may use BigISP's nameserver, 
NS1.BIGISP.NET.  BigISP creates an object in the database pointing to the 
nameserver and names it "NS1-BIGISP".  SmallCo has a lot of domains and 
realizes that they may want to get their own name servers later on, so they 
create a new object pointing to the same nameserver and call it 
"NS1-SMALLCO".  Later on, SmallCo does in fact get their own nameservers, 
so they point "NS1-SMALLCO" at their new nameserver, 
TINY.SMALLCO.COM.  This allows them to modify the nameserver information on 
all of their domain names by making a simple modification to the nameserver 
object, and doesn't affect BigISP's use of NS1.BIGISP.NET in any way.

If registries or registrars want to make each nameserver an attribute of a 
domain that doesn't apply to any other domains, they can simply create a 
new nameserver object for each domain.  This is slightly inefficient, but I 
don't know why this is a desirable goal in and of it self in the first place.

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

This is already dealt with by the existing requirements.  The IP address of 
a name server is only required (indeed, is only allowed) if the name server 
is "registered within the registry's authoritative TLDs".  So, only the 
.NET registry needs to worry about the IP address of NS1.BIGISP.NET.  In my 
scheme, we'd only want one version of the name server to actually have an 
IP address to avoid states where multiple pointers have the same name but 
different IP addresses.

Jordyn