any solution for this setting ? with DNS ? possible ??

[Kevin Darcy]

If you list both DNS servers in the NS records of your zone, then you already
have automatic failover for other servers trying to resolve names in that zone.
DNS is built with this kind of redundancy; it's just automatic, assuming you
configure things correctly. So the only *hard* issue here is how to provide the
failover redundancy for the web servers...

To do this with DNS, there's no really *good* way until all clients know about
"SRV" records. These relatively-new resource records add a layer of indirection
to the resource-location process, and have "preference" values associated with
them, so clients using them know exactly in what order servers should be tried.
Unfortunately, SRV-aware web clients are probably years away.

The simple-minded DNS-based approach is to just change the A record for the
website when the main box goes down (possibly using some sort of automated
script, possibly making the change via Dynamic Update). The main problem with
the simple-minded approach is caching: anyone who has the old record cached in
some intermediate nameserver will still go to the "dead" server even if the A
record has been changed on the master and the change has been propagated to all
of the slaves. Unlike NOTIFY in the master/slave context, there's no practical
way to tell every caching nameserver on the 'Net that a particular A record has
changed, and that they should all come and fetch the new value.

A refinement of the simple-minded approach is to have the name of the website
resolve to *both* addresses, and arrange for them to always be given out in the
appropriate order, i.e. main website first, backup second. This can be achieved
by specifying a "fixed" rrset-order on the master and all slaves for the zone
(you need at least BIND 8.2 for this, and for security reasons that means you'd
be wanting to run BIND 8.2.2 patchlevel 5). Some clients are smart enough to
automatically failover, so for those clients this means more availability
(after a short failover delay) during a failure of the main box, even if they
get a "stale" RRset. Then again, some clients are *not* smart enough to do this
failover, so it's a partial solution at best. Moreover, caching complicates
things here as well: for multi-valued A records, intermediate caching servers
will tend to randomize/round-robin the order of the answers they give out. This
re-ordering effect actually *helps* you in failure mode -- it means that
approximately 50% of the clients getting a stale RRset will still be able to
connect without any failover delay -- but the flip side is that under normal
circumstances, when the main box is up, it means that there will be a certain
amount of "leakage" to the backup webserver. If you don't want to continually
mirror the website contents, you can of course deal with this leakage traffic
straightforwardly via a web redirect on the backup webserver, but that will add
latency. When the main website fails, then remove its A record from the RRset
and turn off the redirect (if any).

Note that with either approach, you can mitigate -- but not completely
eliminate -- the effects of intermediate caching servers by making the address
records volatile (by reducing their TTL values). But this will greatly increase
the traffic to your nameservers for that name, not to mention the extra work
you'll cause for all other nameservers on the 'Net to constantly re-query the
name. Overall, it's a Bad Thing, but many folks resort to it nonetheless.

There are non-DNS solutions to this problem, of course. The obvious one is to
just have lots of redundant network paths so that access is "never" (never say
never) lost to the main webserver, and of course the webserver itself should be
clustered or high-availability so that it "never" goes down, but this "brute
force" approach can get expensive. And then there are specialized
hardware/software failover solutions, which also tend to be expensive. Some of
these make *both* servers look like the same IP address, and the failover
happens transparently. Some of them also integrate dynamic load-balancing
between webservers, which is probably something you want if you outgrow your
current webserver capacity.


- Kevin

DNS help wrote:

> Hi all experts.. I have a question for you.. hope you can help me
>
> If you have 2 physical different locations, e.g. Toronto and Chicago, you
> have web and DNS servers on each site, what will/can you do if T1 connection
> to Toronto office is down, and you want to point all the web requests to
> Chicago's web site ??
>
> ----------                               -----------------------------
>               | ------------------- |  primary web  (Toronto)
>               |                               |  primary DNS server
>               |                               ------------------------------
> internet   |
>
>                ------------------------------
>               | -------------------- | backup web   ( Chicago )
>               |                                | secondary DNS server
>
>                ------------------------------
>               |
> ---------
>
> THANKS IN ADVANCE