<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16850" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2>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.
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2>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. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=374020622-23072009><FONT face=Arial
color=#0000ff size=2>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...</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><B><FONT face=Verdana color=#000080 size=1>Gord Taylor (CISSP, GCIH,
GEEK)<BR></FONT></B></P>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><BR><B>Sent:</B> 2009, July, 23 5:45 PM<BR><B>To:</B>
Taylor, Gord<BR><B>Subject:</B> Re: A smarter stub
resolver??<BR></FONT><BR></DIV>
<DIV></DIV>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.<BR><BR>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.<BR><BR>-B<BR><BR>
<DIV class=gmail_quote>On Wed, Jul 15, 2009 at 10:04 AM, Taylor, Gord <SPAN
dir=ltr><<A
href="mailto:gord.taylor@rbc.com">gord.taylor@rbc.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>I've
frequently run into a problem that the stub resolver just isn't<BR>very
dynamic in its selection of name servers - especially when dealing<BR>with
time-sensitive apps. If the first DNS server in the list is down,<BR>the
applications may slow down due to the constant retransmits. Given
a<BR>resolv.conf like the one below, the xNix box will ALWAYS query the
first<BR>DNS server, event if it's down. So, every single DNS query (think of
how<BR>many reverse lookups a mail server, or Kerberos will do), there's a
2<BR>second delay.<BR><BR>Is there a "smarter" stub resolver that acts more
like a DNS server<BR>using Round Trip Time (RTT) to pick the "best" DNS server
from the list?<BR>We run well over 500 xNix boxes (and growing), so running
DNS on each of<BR>these just isn't a viable option to get round the DNS timing
issues.<BR><BR>Nameserver 10.10.10.1<BR>Nameserver 10.10.10.2<BR>Nameserver
10.10.10.3<BR>Options retry:2<BR>Options retrans:2<BR><BR><BR>Gord Taylor
(CISSP, GCIH,
GEEK)<BR><BR><BR>_______________________________________________________________________<BR><BR>This
e-mail may be privileged and/or confidential, and the sender does not waive
any related rights and obligations.<BR>Any distribution, use or copying of
this e-mail or the information it contains by other than an intended recipient
is unauthorized.<BR>If you received this e-mail in error, please advise me (by
return e-mail or otherwise) immediately.<BR><BR>Ce courrier électronique est
confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations
qui s'y rapportent.<BR>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.<BR>Si vous recevez ce courrier
électronique par erreur, veuillez m'en aviser immédiatement, par retour de
courrier électronique ou par un autre
moyen.<BR><BR>_______________________________________________<BR>bind-users
mailing list<BR><A
href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</A><BR><A
href="https://lists.isc.org/mailman/listinfo/bind-users"
target=_blank>https://lists.isc.org/mailman/listinfo/bind-users</A><BR></BLOCKQUOTE></DIV><BR><pre>_______________________________________________________________________
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.</pre></BODY></HTML>