BIND Suitability For Providing Failover Web Server Management

[Kevin Darcy]

Matt Brooke wrote:

>I'm trying to find a low cost way of manging a situation which exists at the 
>moment.
>
>I host a website on a .uk.com domain through a UK registrar. All requests 
>for this website come through their name servers and through our firewall to 
>arrive at a single machine which then serves the web site.
>
>However when the web site goes down we have no way of quickly changing to a 
>back up server.
>
>The thinking I had was to use an internal DNS server for managing all the 
>external dns names and appropriate web sites which are hosted. If for 
>example one of the web servers was to fail the internal DNS server could be 
>instantly switched over to a failover machine.
>
>Now the issue I have as to how this would be implemented if at all. Would 
>the external DNS names need to have the nameservers changed to the new 
>internal ones (red side accessible), adding the issue of a 6 hour update 
>propogation or would i be able to route all traffic through the firewall to 
>the dns server which would the route the traffic to the appropriate server 
>which was up.'
>
OK, pet peeve of mine: DNS is not a *routing* protocol. Nothing *routes* 
through DNS. DNS is a *mapping* or *translation* or a specialized 
*database* protocol. Once the DNS client software gets an answer from 
DNS, the job of the DNS server is basically *over*: the DNS client 
software passes the information back as an address or multiple addresses 
(typically) to the invoking app, which then makes an entirely 
*independent* connection (I'm using "connection" loosely here; it could 
actually be a connectionless transaction) to its target, without 
involving DNS or the DNS server at all, at that point.

With that in mind, hopefully it's clear that you can do whatever you 
want with your DNS infrastructure and it has no *direct* effect on your 
webserver failover strategy. Because the connection from the client to 
its target does not *route* through the DNS server -- it's a logically 
separate thing.

At the risk of going off-topic, then, your basic challenge is to provide 
web-server redundancy. I would say if the primary and backup webservers 
are on the same subnet, then you should just re-address the backup as 
the primary in case of failure (this should be scriptable). This 
failover strategy therefore wouldn't involve DNS at all. Failing that, 
you could implement DNS-based failover by automatically changing the A 
and/or CNAME records for the relevant websites in case of failure. The 
challenge there, however, is that the old information may be cached and 
clients operating from cached data may continue to hammer on the dead 
webserver. You can reduce the cache persistence of your own data by 
reducing the TTL on the records, but it's rather anti-social to lower it 
_too_much, solely for failover purposes, because you are increasing the 
workload on your nameservers and the resolvers of everyone who is trying 
to resolve those names, for an eventuality that hopefully will only 
occur once in a great while. Another, kludgier option is to have the 
relevant website names resolve to the addresses of *both* the primary 
and backup webservers, with the backup webserver issuing an HTTP 
redirect whenever it's not primary: in case of failure of the primary, 
remove the redirect from the backup and start serving content. There are 
other options, I'm sure, but I'm not a web infrastructure expert...

                                                                         
                                                                  - Kevin