Possible to redirect if domains' website is down?

Kevin Darcy kcd at daimlerchrysler.com
Wed Sep 13 22:25:13 UTC 2000


Normally, folks want the failover to go to a backup web server, which would
mirror the main webserver as much as possible, rather than just a page that
says "we're down". But the goal is basically the same, i.e. to get the clients
to some other web server when the main one is down. Here's a
(slightly-modified) response I gave to the normal webserver-failover-using-DNS
question, just ignore the term "backup" and the part about mirroring webserver
contents:

> 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 applications 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

John Cassel wrote:

> Not sure if this would/could be handled by dns, but will try anyway.  Was
> wondering if I could set it up so that if the website/ip is down for a given
> domain  MYDOMAIN.COM pointing to 99.99.99.99 that it would automatically
> redirect the user to 88.88.88.88
>
> Sorta like a primary vs. secondary dns server does.. if one is down.. go to
> the next.
>
> I seriously doubt that this is possible with or without dns, but thought it
> would be nice for customers' sites if it could.
>
> Basically if one of our servers happens to go down for reboot or whatever,
> they get redirected to a site that explains what is happening... instead of
> timing out in their web browser...
>
> Same lines as round-robin dns stuff....
>
> Thx for any help...
>
> John






More information about the bind-users mailing list