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

Thu Sep 11 23:57:35 UTC 2014

Robert wrote:
> 
> Can't you win in either case?  If they don't re-resolve you could just
> move everyone else off of those IPs by updating the DNS entries for
> the unique nameserver labels to those zones. If they do re-resolve you
> just move that single unique name to a different IP.
> 

I'm not sure what you mean by re-resolve, do you mean re-delegate?

You could move everybody off of the ns set under attack, it's easier to
do if they are all using the same nameserver records (provided you've
isolated the domain under attack and changed it's delegation to
something else first).

It would be harder to do that if each domain were using it's own vanity
NS. In fact in times we've done pretty well that, the domains using
vanity nameservers - pointed at our IPs (without us even realizing
it[1]) had the effect of those domains being "left behind" in the move.

> In either case having the flexibility to affect change at the single
> zone seems desirable - why would I want my domain to be tied to the
> fate of your zone? As Colm points out the tradeoff here is between
> cache-ability of nameserver records vs shared fate.
> 

Yes, I think having that flexibility is very important and handy, I'm
just not sure vanity nameservers - in the way I understand that to mean
- gets you there.

Having a unique set of nameserver permutations per zone could get you
there. If you have three /24's, one for each nameserver node, you could
have over 15 million permutations.

We're in the process of moving toward that sort of a methodology.

- mark

[1] Which brings up an old gripe I've had for a long time, if we're
going to talk about registry rules on creating nameserver records,
wouldn't it be nice, shouldn't it be nice, for nameserver operators to
have some sort of mechanism to approve or at least *refute* domains that
may delegate to them, perhaps without their knowledge or against their
best interests?

In other words, it would be nice to be able to undelegate a domain from
one's own nameservers without having the co-operation of the domain's
registrar.

> 
> .r'
> 
> 
>> Colm MacCárthaigh wrote:
>>> 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
>>>
>>>
>> --
>> Mark E. Jeftovic <markjr at easydns.com>
>> Founder & CEO, easyDNS Technologies Inc.
>> +1-(416)-535-8672 ext 225
>> Read my blog: http://markable.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
> 

-- 
Mark E. Jeftovic <markjr at easydns.com>
Founder & CEO, easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
Read my blog: http://markable.com