True DNS Backup

D. Stussy spam at bde-arc.ampr.org
Mon Mar 3 21:36:52 UTC 2008


"Chris Buxton" <cbuxton at menandmice.com> wrote in message
news:fqhb7l$ska$1 at sf1.isc.org...
> On Feb 28, 2008, at 8:35 PM, D. Stussy wrote:
> > "Chris Buxton" <cbuxton at menandmice.com> wrote in message
> > news:fplp2q$2o8j$1 at sf1.isc.org...
> >> On Feb 21, 2008, at 9:58 PM, Gregory Hicks wrote:
> >>> If either network provider fails, but the other remains up, the
> >>> external world will continue to query your servers providing the
> >>> network does what it is supposed to do and provides routes TO your
> >>> servers.  They will try one then the other server.  Whichever one
> >>> provides the 'fastest' (relatively) response time is the one that is
> >>> actually going to get queried.
> >>
> >>
> >> One point I would add is, all zones must be delegated to all four IP
> >> addresses for this to work. That generally means giving each name
> >> server, in this case, two different names, one for each address.
> >
> > Why?  Why can't one have two names that each have two address records?
>
> I said "generally". If you can convince your domain registrar (or
> whoever runs the parent zone) to allow two glue records per name
> server, my understanding is that that would work fine. Otherwise,
> you'll need four names for this situation.

Any registration service that doesn't support multihomed glue records needs
to be shot.

> > There should be another server (in another geographic location) as
> > both of
> > these are on the same local network (regardless of which address is
> > used to
> > reach them).
>
>
> If the OP plans to use views to route web requests, for example, over
> the same network connection that the DNS requests come over, then
> having an offsite slave will spoil this.

Noted, but that's not sufficient reason to disregard the "best current
practice" for disaster recovery.  Regardless, shouldn't it be the client
which determines which address is "closer" after it receives ALL addresses?
A client, when doing a DNS lookup, doesn't necessarily pick the closest DNS
server first - but a RANDOM one from the list (which may be topographically
further away than the other choices).  Using views to serve a preferred
order of addresses makes assumptions that may not be true in many cases.




More information about the bind-users mailing list