If you're on a closed network and not using forwarders, then you'll
also
need a hints file and associated hints-file definition in named.conf,
of
course, but even so, we're still not talking about adding a great deal
of additional care and feeding...
It's not much, I'll gladly concede, but
At Wed, 15 Jul 2009 10:04:30 -0400,
Taylor, Gord gord.tay...@rbc.com wrote:
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
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,
: 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
Todd Snyder wrote:
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.
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
6 matches
Mail list logo
