Second Nameserver

[Kevin Darcy]

First of all, let me point out that nameserver failover is currently
built into the DNS protocol. As long as you have multiple nameservers
defined for your domain, and replication is working and some reasonable
percentage of them are reachable at any given time, your domain names
should resolve. That's the good news. The bad news is there is currently
no good way to do webserver failover using DNS. If and when browsers
support SRV records for web access, then this kind of thing will be
eminently possible, but that's currently a ways off (see
http://bugzilla.mozilla.org/show_bug.cgi?id=14328 for recent attempts to
get this effort off the ground).

About the best you can do right now is mirror your content to the backup
site and advertise *both* A records -- modern browsers will failover
over to the second A record in the list after a short delay. If you
control all of the authoritative nameservers for the domain, you can
help to "steer" more traffic to the primary site by defining a
"fixed" rrset-order for the name on all of those servers, but you're
going to get some leakage to the backup site because other nameservers
will tend to cache the answer and then give it back out in cyclic aka
"round-robin" order. You can minimize this effect somewhat by lowering
the TTL values on your records, however, this will increase DNS traffic
to your servers, and it's basically a rather anti-social thing to do
since it makes everyone *else*'s nameservers overwork as well. It's not
a scalable solution to the general Internet problem of providing
webserver redundancy.

Another approach is to have a monitoring script which automatically
changes the A record when the primary goes down. You could use Dynamic
Update for this. Note that here again you are at the mercy of other
nameservers' caches -- many clients won't see the change for a while
after you make the change, and unlike the "multiple A record" approach
above, they won't have any chance to failover to the backup webserver
until the local nameserver's cache entry is refreshed. Again, you can
minimize the caching effects by reducing your TTL's, but it's a Really
Bad Idea. Imagine if everyone reduced the TTL's on all of their records
to 0 -- the whole Internet DNS could come crashing down on our heads.
(Sorry to sound a little bit like Chicken Little there, but an
increasing number of folks -- including a few load-balancer vendors, who
should know better -- seem to think low or 0 TTL's are no big deal.
I guess somewhere along the line they just dispensed with the idea of
using the protocol efficiently and properly).

Lastly, I understand that there are some tricks that can be played with
BGP to dynamically re-route the same address to a different physical
location. Not being a BGP expert, I'll defer to others to explain how
that works (and it's not really germane to this list anyway).


- Kevin

Michael McQuarrie wrote:

> I need to set up a secondary name server that would
> take over in the event of a primary failure...the
> catch is that in the event of the primary name server
> being destroyed there is a good chance that the web
> servers would be destroyed also.  That means that the
> secondary would be pointing to web servers that were
> not responding if It took over.  by the way the
> secondary is at a different site than the primary and
> web servers.  I will have the secondary also equipped
> to act as a web server that can display a splash
> screen that says we're having technical difficulties.
> How can I in the event of a primary failure have the
> secondary become SOA and point everything to itself as
> the web server? if unclear let me know...
>
>