How to set up failover for a single web server using two ISPs

If you want to delegate authority for a section of your domain you are going to need to add another level to the hierarchy.

When a recursive DNS server asks for the address for ftp.econemon.com it is going to go through a number of steps. First it is going to ask one of the root servers which will reply with the name servers for the .com domain (this step will likely be cached and only done infrequently). It will then ask the .com servers and they will respond with the name servers for the econemon.com domain. Finally it will ask these servers for the address record for ftp.econemon.com.

In theory you could simply add ftp.econemon.com as an NS entry in the parent zone

e.g:

services     NS    ns1.econemon.com.
ns1          A     192.0.2.1

And then create ftp.econemon.com as a zone in your name server. But if you do it this way you will have to create a new zone per server. What you probably want to do is ask your provider to add a delegated subdomain.

e.g.:

services     NS    ns1.services.econemon.com.
services     NS    ns2.services.econemon.com.
ns1.services A     192.0.2.1
ns2.services A     192.0.2.2

You can then add services.econemon.com as a zone on your name servers and simply add new entries as you need them in this single zone.

If you really need the short names too it shouldn't be too much trouble to get CNAME records added such that ftp.econemon.com has a canonical name of ftp.services.econemon.com which leaves you able to change the IP address whenever you want to and allows users to use a short name.

ftp.econemon.com.    CNAME    ftp.services.econemon.com.

By 'DNS failover' I take it you mean DNS Round Robin combined with some monitoring, i.e. publishing multiple IP addresses for a DNS hostname, and removing a dead address when monitoring detects that a server is down. This can be workable for small, less trafficked websites.

By design, when you answer a DNS request you also provide a Time To Live (TTL) for the response you hand out. In other words, you're telling other DNS servers and caches "you may store this answer and use it for x minutes before checking back with me". The drawbacks come from this:

• With DNS failover, a unknown percentage of your users will have your DNS data cached with varying amounts of TTL left. Until the TTL expires these may connect to the dead server. There are faster ways of completing failover than this.
• Because of the above, you're inclined to set the TTL quite low, say 5-10 minutes. But setting it higher gives a (very small) performance benefit, and may help your DNS propagation work reliably even if there is a short glitch in network traffic. So using DNS based failover goes against high TTLs, but high TTLs are a part of DNS and can be useful.

The more common methods of getting good uptime involve:

• Placing servers together on the same LAN.
• Place the LAN in a datacenter with highly available power and network planes.
• Use a HTTP load balancer to spread load and fail over on individual server failures.
• Get the level of redundancy / expected uptime you require for your firewalls, load balancers and switches.
• Have a communication strategy in place for full-datacenter failures, and the occasional failure of a switch / database server / other resource that cannot easily be mirrored.

A very small minority of web sites use multi-datacenter setups, with 'geo-balancing' between datacenters.