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

[Colm MacCárthaigh]

Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?

One the one hand, requiring that nameservers be registered creates
downward pressure on the number of active authoritative name server
names in the world, which has benefits for cache efficiencies (ie many
zones delegated to the same names).

One the other hand, it can be beneficial to give every zone unique
name server names (in-zone vanity names, or otherwise), even if those
names resolve to the same name-servers. That would makes it easier to
manage single zone migrations and things like DDOS isolation. These
days I think it might be as common to move a single zone around as it
is to renumber a host.


On Thu, Sep 11, 2014 at 9:06 AM, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
Colm