A smarter stub resolver??

Mon Jul 20 20:25:55 UTC 2009

The problem with this approach is when you are running a couple thousand servers - suddenly, you are running a couple thousand more instances of BIND that need monitoring/patching/care/feeding.

A more clever resolver, or a simpler caching setup locally would be ideal.  Otherwise, you could redo your overall DNS architecture to use something like anycasting so that there are multiple sources (potentially) for each of your nameserver entries, so you're less likely to have one drop.

However, this isn't ideal.  A smarter resolver would be fantastic, but with smarts comes complexity, which brings more room for errors and/or vectors for attack.

You'd think this would be a common concern in large server deployments.  As soon as you lose one of your resolvers, even if it's painfully obvious that the resolver is down, the resolver will continue to send queries to that host.

I guess it's a trade off, but there's really only 2 options ... maybe more are needed.

t.

-----Original Message-----
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Kevin Darcy
Sent: Monday, July 20, 2009 1:30 PM
To: bind-users at lists.isc.org
Subject: Re: A smarter stub resolver??

Rather than applying lipstick to the pig, why not run a local 
caching-only resolver? Move up and out of the stub-ville slums. A local 
instance of named doesn't take up that much server resources (disk, 
memory, CPU), and pays you back by *not*, as a stub resolver does, using 
network resources, and incurring network latency, for each and every lookup.

                           - Kevin

Taylor, Gord wrote:
> 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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Taylor, Gord
> Sent: 2009, July, 15 10:05 AM
> To: bind-users at 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 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.
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>   

_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.