NS failover as opposed to A record failover

Scott A. Wozny sawozny at hotmail.com
Wed Feb 26 17:35:12 UTC 2020


Thank you for the feedback, Tony.  I think a better understanding of what's going on under the hood will prove useful in both designing my operational management strategy as well as just talking me down off the ledge.  :)  Much obliged.  :)


Scott


________________________________
From: Tony Finch <dot at dotat.at>
Sent: February 26, 2020 10:05 AM
To: Scott A. Wozny <sawozny at hotmail.com>
Cc: bind-users at lists.isc.org <bind-users at lists.isc.org>
Subject: Re: NS failover as opposed to A record failover

Scott A. Wozny <sawozny at hotmail.com> wrote:
>
> Failures aside, I’m worried about creating a bad user experience EVERY
> time I need to take a DNS server down for patching.

I generally let resolvers handle retry/failover when I'm patching my
authoritative servers. Each resolver that encounters an authoritative
server that is down will retry on another server within a few seconds, and
should send follow-up queries to more responsive auth servers. There are
several retries within the libc resolver timeout, so there are multiple
opportunities to automatically deal with an outage within a reasonable
amount of time. So the badness isn't that terrible. (i.e. less than the
load time for a web page with megabytes of JavaScript.)

I reckon this should be good enough for you, because it's a similar amount
of badness that your users will encounter from your DNS UPDATE web server
failover setup.

If you want something better, on my recursive servers I use keepalived to
move the service IP addresses off servers while they are being patched.
You can do something similar for auth servers, if you have a little
cluster in each location. On your web servers, keepalived and HAproxy is
supposed to be a good combination (though I have not tried it myself).
For servers that are too far apart for layer 2 failover to work, you'll
need to get funky with anycast.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Tony Finch's homepage<http://dotat.at/>
dotat.at
Tony Finch's homepage. my work web page (including stuff about email, especially in Cambridge University) my blog (in which I mostly write about things I'm working on) my Twitter account (to which I feed my link log and a steady diet of retweets) my link log (wildly weird and wonderful) My git repositories on chiark and on github; My git server at work.

German Bight: Northwest backing southwest later 4 to 6. Slight or moderate.
Showers. Good, occasionally moderate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200226/e14aaf8b/attachment.htm>


More information about the bind-users mailing list