A smarter stub resolver??

[Taylor, Gord]

Thanks for the response. I'm replying to the list as well since I haven't done that yet, and others may benefit from the same information. 
 
Load balancing is one of the options we had already tabled, but it means doubling our entire distributed infrastructure (about 20 distinct locations), and many of them don't have load balancers. So the cost of doing anything wide-scale is extremely high, that's why we were looking for something that could be rolled out everywhere.
 
One suggestion I was given, and we're now looking into, is using AnyCast. Since we're already running OSPF in most areas of our internal network, we could do this without any additional hardware costs, and allows an even broader geographic failover than we offer with hardware load balancing. Assuming we can get this working with few problems it should meet the business requirements and leave us with a much more resilient DNS infrastructure. 
 
The only draw-back I see are "intermittent" problems with clients if one DNS server in the AnyCast address pool is acting funny. This shouldn't be too hard to troubleshoot, though, since devices will have an affinity for the "closest" server on a given AnyCast address.
 
If anyone on list has experience with using AnyCast & DNS, I'd love to hear any of the "gotcha" moments or tips you may have...

Gord Taylor (CISSP, GCIH, GEEK)


 

________________________________


Sent: 2009, July, 23 5:45 PM
To: Taylor, Gord
Subject: Re: A smarter stub resolver??


We put our DNS servers behind a hardware load balancer.  The load balancer takes care of the magic for us.  If a DNS server fails it is seamless for our hosts.

The target DNS servers for our load balancers are both physically local DNS servers and remote DNS servers.  Given that if our load balancers puke we are SOL anyway, this is acceptable for us.

-B


On Wed, Jul 15, 2009 at 10:04 AM, Taylor, Gord <gord.taylor at rbc.com> wrote:



	I've frequently run into a problem that the stub resolver just isn't
	very dynamic in its selection of name servers - especially when dealing
	with time-sensitive apps. If the first DNS server in the list is down,
	the applications may slow down due to the constant retransmits. Given a
	resolv.conf like the one below, the xNix box will ALWAYS query the first
	DNS server, event if it's down. So, every single DNS query (think of how
	many reverse lookups a mail server, or Kerberos will do), there's a 2
	second delay.
	
	Is there a "smarter" stub resolver that acts more like a DNS server
	using Round Trip Time (RTT) to pick the "best" DNS server from the list?
	We run well over 500 xNix boxes (and growing), so running DNS on each of
	these just isn't a viable option to get round the DNS timing issues.
	
	Nameserver 10.10.10.1
	Nameserver 10.10.10.2
	Nameserver 10.10.10.3
	Options retry:2
	Options retrans:2
	
	
	Gord Taylor (CISSP, GCIH, GEEK)
	
	
	_______________________________________________________________________
	
	This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations.
	Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.
	If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
	
	Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
	Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
	Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
	
	_______________________________________________
	bind-users mailing list
	bind-users at lists.isc.org
	https://lists.isc.org/mailman/listinfo/bind-users
	


_______________________________________________________________________

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations.
Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.  

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090723/fd7f0d1b/attachment.html>