{"id":388,"date":"2016-05-27T14:35:15","date_gmt":"2016-05-27T18:35:15","guid":{"rendered":"https:\/\/domainsure.com.wp.easypress.ca\/?p=388"},"modified":"2019-02-27T14:36:51","modified_gmt":"2019-02-27T19:36:51","slug":"the-case-for-hot-swappable-nameservers","status":"publish","type":"post","link":"https:\/\/domainsure.com\/articles\/the-case-for-hot-swappable-nameservers\/","title":{"rendered":"The Case for Hot Swappable Nameservers"},"content":{"rendered":"

\"\"<\/p>\n

(reprint of an article we once wrote for CircleId<\/a>) <\/em><\/p>\n

\n

Earlier this week we announced our “Proactive Nameservers<\/a>\u201d, which is just marketing speak for what it really is: hot swappable nameservers or nameserver fail over.<\/p>\n

What is it?<\/strong><\/p>\n

Basically this:<\/p>\n

    \n
  1. you define some warm spare nameservers that are not normally in your delegation<\/li>\n
  2. you load those servers up with your zone data (most likely by having it slave from your hidden master)<\/li>\n
  3. you then monitor everything to a) make sure the current delegation is working and b) your backups are “ready” to step in should you need them (the last thing anybody wants to do would be to swap in some nameservers with out of date zone-data in the event of a failure)<\/li>\n
  4. in the event of a failure or degraded performance with your current delegation, the system can either a) remove problematic servers from your delegation or b) change the delegation entirely to your backup pool.<\/li>\n<\/ol>\n

    That’s it. It’s basically what every webmaster, IT department and CTO wishes they had set up before their web hosting provider, registrar or managed DNS provider got blown away in a DDoS or had their “router tables corrupted”, and then wishes they would be able do (switch their delegation) but can’t do while that same provider (and all its hosted domains) is down hard.<\/p>\n

    What you see now are frantic workarounds where people stick the IPs for their nameserver provider into \/etc\/hosts so they can log into the otherwise unreachable management panel, figure out how to dump their zone records (provided that their DNS host even allows that) and then setting them up someplace else and then finally switching the nameserver delegation. By the time they get to this point it’s usually been a) a few hours after the outage started before it occurred to anybody that this would work and b) a few minutes before the outage ends anyway.<\/p>\n

    So what we’re doing here is setting all that up in advance, monitoring for conditions that require it to happen, and then automating its execution when the circumstances arise.<\/p>\n

    You may never need this, but it is impossible to know if you will or not.<\/p>\n

    Why is this better than using multiple DNS providers in your delegation from the outset?<\/strong><\/p>\n

    Using multiple DNS providers all the time is in our minds a best practice. It may be more work to keep the various solutions talking to each other and in sync but it’s worth it. We have had numerous customers in the past using both us and one or two other providers concurrently that were not impacted when we or the other providers were DDoS-ed. Earlier this year, the number of our users on our easyRoute53 integration with Amazon’s Route 53 skyrocketed 400% in one day (the day\u00a0<\/span>after<\/em>\u00a0<\/span>we got DDoS-ed).<\/p>\n

    But there are some limitations and some caveats to loading up your nameserver delegation with multiple provider nameservers at the same time:<\/p>\n

    1) I’ve seen people pile in 10 or 13 nameservers in an effort to achieve super-redundancy. Which works up to a point. Unfortunately what can also happen is that bloats the size of the DNS response packet past 512 bytes and thus triggering TCP retries on all their queries. This slows things down and we’ve seen issues lately where mobile clients on some networks do not handle it gracefully, actually resulting in failed lookups.<\/p>\n

    2) If you have a lot of nameservers in your delegation and some of them are non-performing (say one of your providers is down), then you again slow things up because initial queries or cache refreshes are going to hit all of your unresponsive nameservers and wait for the ensuing time-outs. With this approach they will only be querying the live, responsive servers.<\/p>\n

    3) You don’t show all your cards. We didn’t envision this as a DDoS mitigation tactic for a domain who is the direct target of a DDoS (the system works better if your provider goes down because of a DDoS against somebody else, which is probably more likely for most businesses). Having said that, if you\u00a0<\/span>are<\/em>\u00a0<\/span>the direct target of a DDoS and you have this in place, you buy yourself some time before the botnet recalibrates and hits your backup pools. You can use that time to arrange or activate other DDOS mitigation such as GRE tunnels or proxies, which will be a lot easier to setup if you’re actually still able to operate.<\/p>\n

    4) Finally there is the syncing issues, which you have in either approach but at least now there’s a process that is actively monitoring if you have a sync issue or not.<\/p>\n

    Where can this go?<\/strong><\/p>\n

    Once you break out of the box where nameserver delegations are assumed to be inert, static obelisks that most people (even IT and web professionals) don’t think about much, and make the leap that your delegations can be responsive and actively optimized; the horizons open up:<\/p>\n