[dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

[Andrew Sullivan]

On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote:
> Many registries, if not most, don't let you delegate a zone to
> arbitrary name-servers. Instead those nameservers need to be
> "registered" in some way.
> 

I don't know about other kinds of registration systems, but in
EPP-based ones this is a consequence of one of the variants of the
data model.

In EPP, there are two ways to create name servers.  One is as an
attribute of the domain object.  The other is as an association
between a domain object and a host object.  What you're seeing, I
expect, as the "registration" is in fact the creation of the host
object.

The host-object approach has a particular advantage.  It isn't quite
true that _anyone_ can create a host object.  "External" hosts
(i.e. out-of baliwick, such as ns1.example.com in the .info registry)
can indeed normally be created by anyone and normally do not take an
IP address (it's a bad idea to have glue there, because it's
out-of-baliwick).  But "internal" hosts take glue, and they are not
allowed to be created unless the superordinate name exists (i.e. you
can't create ns1.example.org in the org registry unless example.org
has already been created; this is required by RFC 5732).  

In at least one registry implementation of which I am aware, the
server policy was that the sponsor of the host object in the
repository had to be the same as the sponsor of the superordinate
domain object (that is, RegistrarA couldn't create a host in
example.info if example.info was registered by RegistrarB).  This may
have been our interpretation of the then-existing EPP draft, though I
suspect we did it for convenience.  I can't recall.  My reading of RFC
5732 is that it does not require this.

The particular advantage that the host-object approach has is that the
original creator of an internal host object gives it an IP address,
and everyone gets the same IP address thereafter.  If the address
changes, it changes once for everyone in the registry.  This in fact
models what happens on the Internet when you renumber a host.  It's
terrible for registry operators, of course, but it's good data
practice.  None of this matters for out-of-baliwick name servers, but
it'd be a bad idea to mix and match the host-object and
nameserver-attribute approaches in the same registry, so EPP prohibits
repository operators from doing both at the same time ("A server
operator MUST use one name server specification form consistently,"
saith RFC 5731).

Anyway, I suspect that's the reason for what you observe.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com