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

Mark E. Jeftovic markjr at easydns.com
Thu Sep 11 16:52:42 UTC 2014


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


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




More information about the dns-operations mailing list