NS failover as opposed to A record failover

Scott A. Wozny sawozny at hotmail.com
Wed Feb 26 17:32:02 UTC 2020


Thanks for the feedback, Bob.  This is encouraging news.  I think now I need to do some testing to see what works best for my application.


Scott


________________________________
From: Bob Harold <rharolde at umich.edu>
Sent: February 26, 2020 9:02 AM
To: Mark Andrews <marka at isc.org>
Cc: Scott A. Wozny <sawozny at hotmail.com>; bind-users at lists.isc.org <bind-users at lists.isc.org>
Subject: Re: NS failover as opposed to A record failover


On Tue, Feb 25, 2020 at 6:38 PM Mark Andrews <marka at isc.org<mailto:marka at isc.org>> wrote:

> On 26 Feb 2020, at 09:51, Scott A. Wozny <sawozny at hotmail.com<mailto:sawozny at hotmail.com>> wrote:
>
> I know this isn’t a question ABOUT BIND, per se, but I think is still a question bind-users might have an answer to. I’ve seen various failover questions on the list, but nothing that talks specifically about NS records (at least nothing in the last decade), so I thought I’d inquire here.
>
> I’m familiar with round-robin DNS and using multiple A records for the same name. I also understand that most clients, if the top server on the list doesn’t respond, will wait ~30 seconds before trying the next address on the list. This is pretty good, as far as automatic failover goes, but still, having X% of your users (X being down servers / all A records offered) wait an extra 30 seconds is not great so I’m going to run a regular health check on my front facing web servers from each BIND server and, if a server stops responding, change my zone file and reload until the server starts responding again, reversing the process. Then X% of my users will only need to wait 30 seconds until I fix the zone file (TTL will also be about the same frequency as the health checks so worst case scenario will be 2xTTL for X% of users having to wait those extra 30 seconds). Overall I’m satisfied with this balance between complexity and resiliency, particularly considering I can do record manipulation in advance of planned maintenance and then this problem only becomes an issue during unexpected outages.

There is nothing that requires clients to wait a full thirty seconds before moving onto the next address.  In fact Happy Eyeballs (RFC 83050) uses sub-second delays before attempting connections to other addresses.  Yes, you
can have multiple connection attempts to different servers in flight at the same time and just take the one that
connects first while dropping the others.  The standard socket API supports this sort of behaviour but most applications doesn’t use it that way.

https://users.isc.org/~marka/ has code samples, that pre-dates Happy Eyeballs, that attempts to connect to multiple addresses at once with small delays.  Once a connection is established the other attempts are aborted.

There are examples using select(), poll() and multiple threads.

> This is all well and good until I think about failure or maintenance of the name servers, themselves. I’ll need to give my registrar my NS IPs for my domain but they will not be nearly as flexible regarding changes as I am running my own nameservers (TTL will probably be an hour, at the very least) which makes maintenance work a MUCH longer process for set-up and tear-down, if I have to make NS record changes in coordination with my registrar. However, this made me wonder, is NS failure responded to in the same way as the failure of an A record? Various Internet randos have indicated some DNS clients and resolvers will do parallel lookups and take the first response and others have indicated that the “try the next record” parameter for NS comms is 5 to 10 seconds rather than 30 and still others claim it’s the same as A record failover at 30 seconds before trying the next candidate on the list. Is there a definitive answer to this or, because it’s client related, are the answers too widely varied to rely upon (which is why the answers on the Internet are all over the map)?

Well you have the stub resolver and the recursive server to talk about.

Stub resolvers generally use low second timeouts before moving on to the next address but some just shotgun every recursive server.

Recursive servers can do the same thing.

The 30 seconds comes from the TCP connect timeout.  Where the TCP/IP stack makes multiple connection attempts over that 30 seconds before giving up.

DNS, initially, is UDP and the client manages retransmission attempts.  Named uses sub second initial timeouts.  Most of the world is less that 200ms RTT from any other point though there are exceptions.

Mark

> Failures aside, I’m worried about creating a bad user experience EVERY time I need to take a DNS server down for patching. I can’t be the first person to run into this problem. Is it just something people live with (and shuffle NS records around all the time) or is NS failover really smoother than A record failover and I should concentrate on keeping my A records current in case of failure OR planned maintenance?
>
> Any feedback would be greatly appreciated.
>
> Thanks,
>
> Scott
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org<mailto:marka at isc.org>


Scott,
   To directly give an opinion on your last question - client applications can often be slow to recover from failed connections, so updating the A records in the zone is a good idea - best to use nsupdate, do not edit zone file and reload.  DNS Recursive resolvers should failover in seconds and remember which authoritative servers are down, so don't worry too much about taking down a server for maintenance, just try to keep it short, and only one at a time.

--
Bob Harold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200226/e4eb91df/attachment-0001.htm>


More information about the bind-users mailing list