On 11 September 2014 09:52, Mark E. Jeftovic <mar...@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 <a...@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 >>> a...@anvilwalrusden.com >>> _______________________________________________ >>> dns-operations mailing list >>> dns-operations@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 <mar...@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@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 _______________________________________________ dns-operations mailing list dns-operations@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