Multihoming using DNS

Kevin Darcy kcd at daimlerchrysler.com
Thu Jan 27 18:03:50 UTC 2000


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.






More information about the bind-users mailing list