Multihoming using DNS

[Barry Margolin]

In article <86p9js$1po$1 at nnrp1.deja.com>,  <jfk63 at my-deja.com> wrote:
>The DNSs resolve www.oursite.com as 1.2.3.4 which is routed through ISP-
>A (what we've got at the moment)
>The TTL on this record is set to be very low as is the refresh
>In the event that the link goes down or other anomalies occur, a script
>(automated or manual) changes the record in the DNS to resolve
>www.oursite.com as 5.6.7.8 (which is routed via ISP-B)

Be aware that refresh time is not used exactly.  First of all, BIND only
checks for domains whose refresh times have run out every 15 minutes.  So
setting refresh less than 900 won't make it refresh any more quickly.
Second, the refresh time only indicates when the slave will put the zone
into its refresh queue.  Depending on how busy the server is and how many
other zones need to be refreshed, it could take a while for it to get to
your zone.  In some anomalous cases I've seen some of our slave servers
take 12 hours to refresh a zone.

>Of, course, it's more complicated than that.
>
>We will need to have a nameserver on the 1.2.3 network and on the 5.6.7
>network (and probably elsewhere). So if the outside world is used to
>getting its info from the NS-A on 1.2.3.x it will have to switch to NS-
>B on 5.6.7.x

That's not a problem.  Just list both servers in your domain registration.
Queries will go to whichever responds more quickly, and they'll fail over
to the other one.

>We will probably use NAT (Network Address Translation) at the edges to
>ensure that the Web Farm can remain consistent
>
>As far as I can tell this should allow for a fairly quick recovery in
>the event that we lose the link to ISP-A.
>
>Clients should only cache the 1.2.3.4 address for a short time - 5 mins
>or so - after which they try and resolve www.oursite.com again. They
>cannot find NS-A (because the link is down) so they fall-thru to NS-B
>this resolves the address as 5.6.7.8

The TTL controls caching in remote name servers.  Some applications
(particularly browsers) contain their own caches, which generally have
hard-coded (or user-settable) timeouts.  I think they usually default
somewhere in the 5-15 minute range.

>Of course we will have to put up with a lot more NS traffic but that's
>not the end of the world.
>
>So....why am I telling you all this...well I'm hoping that someone may
>have already done this, in which case you can tell me whether it is
>likely to work.

It seems like it would work.  You could also look into installing
something like Distributed Director, which automates the entire thing.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.