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

[Robert]

On 11 September 2014 09:52, Mark E. Jeftovic <markjr at easydns.com> wrote:
> Vanity nameservers would not be very useful in DDoS mitigation (in terms
> of isolating your target) unless you actually create unique IP address
> nameserver records for each one.
>
> That's all you'll see in the attack, which IP's the attack is coming
> toward, not the hostnames of the vanity nameservers themselves (although
> I suppose it's possible the botnet would constantly be doing DNS lookups
> of those vanity nameservers, but they could just as easily do it once,
> at the beginning of the attack and then cache their responses).
>
> - mark
>

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.

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.


.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