Multihoming using DNS

[Kevin Darcy]

On second thought, you'd probably still want the script kludge: not all
browsers implement automatic failover (still!), plus browsing will be slower
if the clients all have to failover for each URL. But rrset-order=fixed would
still ease the failover and should probably be implemented in addition to the
script kludge...


- Kevin

Kevin Darcy wrote:

> If you're going to lower your TTL's _anyway_, why not just use the
> rrset-order statement to give out the webserver addresses in "fixed" order?
> Then you wouldn't need the script kludge. Of course, the rrset-order's
> would have to be configured on the master and all slaves to be effective.
> And you'd still get a certain amount of spillover to the "B" machine since
> intermediate nameservers will round-robin the answers as long as they are
> in cache.
>
> As for nameserver redundancy, you could have the slaves be *anywhere*, they
> wouldn't have to be on networks 1.2.3 and 5.6.7. If you have multiple
> NS references to the same multi-homed machine, then you get slower
> convergence if that machine happens to go down. It's best to spread your
> NS'es across multiple machines (preferably on diverse networks), not just
> multiple interfaces.
>
> - Kevin
>
> jfk63 at my-deja.com wrote:
>
> > Multihoming Using DNS
> >
> > We host a web site and we want to ensure greater resilience by using
> > more than one ISP.
> >
> > Clearly we can go the whole hog and implement BGP, but this is a major
> > upheaval and will have very severe consequences if we don't configure
> > it correctly (so that is a longer term prospect).
> >
> > We plan - at least in the short term - to employ the DNS to make use of
> > this second link...as described below:
> >
> > 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)
> >
> > 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
> >
> > 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
> >
> > 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.
> >
> > I'm sure that most of the people in this group have far more DNS
> > knowledge than I have. If you reckon this is a non-starter please let
> > me know.
> >
> > >From our point of view this is a "minimal change" solution. What we
> > have works very well but we are aware of the risk of using one ISP (we
> > have resilience built-in in most other areas).
> >
> > As I mention at the beginning this will probably not be our ultimate
> > solution so if any of the people reading this email can suggest more
> > elegant solutions I will be interested to read them.
> >
> > Thanks
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.