True DNS Backup

Chris Buxton cbuxton at menandmice.com
Wed Mar 5 01:58:29 UTC 2008


On Mar 3, 2008, at 1:36 PM, D. Stussy wrote:
> "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:
>>> 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.


I said nothing about a preferred order of addresses, which, given that  
resolving name servers will effectively randomize them, is a generally  
useless practice. And the OP said nothing about disaster recovery,  
just about handling the case when one or the other ISP connection (but  
not both) goes down - fault tolerance (and some load balancing) for  
upstream connections.

The client (the stub resolver) doesn't pick a DNS server to query, the  
resolving name server does. And while for the first query into the  
zone, the resolver will choose randomly, once it has sufficient data,  
it will tend to query whichever address responds fastest. This  
provides the load balancing aspect.

For fault tolerance, consider that if a line goes down, the DNS server  
will retry the other available name server addresses until it gets an  
answer - this should typically be speedy enough that the web browser  
will never notice. In order for the browser to connect to the web  
server using the line that is still up, the response from the DNS  
server should contain just one A record, giving the address of the web  
server that is available over the same ISP connection as the DNS  
server itself. This can be accomplished using views on the DNS  
servers, with different IP interfaces for the different routers.

(I'm sure this strategy has been described endlessly on the list  
before, but I don't have a handy link to any archive or FAQ. It was  
faster to retype it than to find such a reference.)

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to which  
it is addressed. If the reader of this message is not the intended  
recipient, you are hereby notified that any retention, dissemination,  
distribution or copy of this e-mail is strictly prohibited. If you  
have received this e-mail in error, please notify us immediately by  
reply e-mail and immediately delete this message and all its attachment.





More information about the bind-users mailing list