I should mention, that I've looked at "options rotate", but the concern is that this will mean retransmits if ANY of the nameservers are down. So, any DNS outage would cause some level of impact to the application.
It also makes it harder for applications to determine if slowdowns are due to DNS name resolution issues. Since 1/3 of the queries will be slower, they'll not think to look at DNS as root cause; they'd probably see it as a utilization issue, or something along those liens. While that may mean I don't get paged, it's not great for the business :) Gord Taylor (CISSP, GCIH, GEEK) -----Original Message----- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Taylor, Gord Sent: 2009, July, 15 10:05 AM To: bind-users@lists.isc.org Subject: A smarter stub resolver?? 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