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.tay...@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@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.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
