Scott A. Wozny <sawo...@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 <d...@dotat.at> http://dotat.at/
German Bight: Northwest backing southwest later 4 to 6. Slight or moderate.
Showers. Good, occasionally moderate.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
