Thanks to all who responded. The original query:
On Fri, Apr 23, 1999 at 10:09:00AM -0400, Hergert, John (PSC) wrote:
> Greetings
>
> Some one on my network team recently noticed that when certain of our more
> intense applications are running they generate a large number (20-30) of
> DNS queries a second seeking the IP address to our DB server. The
> natural question came up, "Isnt there a way to cache this information in
the
> client resolver so that we dont have to wait for DNS to respond?"
>
> Is there some switch or parameter that controls this caching on the
client?
>
> Thanks
> John Hergert
> Volkswagen of America
The short anser is that no there is no configurable parameter to turn on DNS
client caching, and all suggested turning on either a local server or adding
names to the host table.
I got responses from:
John Speno <speno_at_isc.upenn.edu>
If it really bothers you, run a caching only DNS server on that
host, and edit resolv.conf to query 0.0.0.0 first.
Arrigo Triulzi <arrigo_at_albourne.com>
How 'bout putting the IP address in /etc/hosts and then checking that
/etc/svc.conf has
hosts=local,bind
Kevin Oberman <oberman_at_es.net>
The DNS client does no caching. That should be a job for the
application.
The other "correct" answer is to run a caching only server on the
client. If the client is DU or any other Unix type OS, this is clearly
the best answer. It's also trivial to set up. Just install a recent
BIND with no primaries or secondaries except for . It still needs a root
hints
file and you may want to specify a forwarder, as well.
Here is a BIND 8 boot.conf for a caching only server:
zone "." {
type hint;
file "root.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
localhost.rev should look like:
_at_ 604800 IN SOA LOCALHOST. Postmaster.LOCALHOST. (
1 ; Serial
14400 ; refresh every 4 hours
7200 ; retry every 2 hours
12096000 ; expire in twenty weeks
86400 ) ; minimum
604800 IN NS LOCALHOST.
IN A 127.0.0.1
Get the current root.cache by running dig with no arguments. and
saving the result.
Then modify /etc/resolv.conf to have the local system as the first
server. Use the actual IP address of the system and not 127.0.0.1.
Jim Bostwick <jim_bostwick_at_cargill.com>
I don't believe the resolver can be made to cache DNS. However, it is
pretty
straightforward to set up a
cache-only nameserver on the client(s) that are generating the heavy load.
Then,
point the client's resolver at the local cache-only server.
The good news is that, once set up, these require essentially zero
maintenance.
Hans Ranke <Hans.Ranke_at_ei.tum.de>
The BIND resolver library is supposed to cache DNS information by default
(as long as the TTL allows). However, as this is stored in each process'
address space, different processes on the same client machines cannot share
this information.
If you have a client machine with many short-living processes that
all need to access the same server, you might consider running a nameserver
in 'cache-only'-mode (i.e. not as primary or secondary server for a zone)
on the client machine and add localhost to the nameserver list
in /etc/resolv.conf.
Hans
Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
I don't know of any way to get the resolver itself to cache DNS information.
There are two possiblilites that come to mind, which might help your
situation:
1. If your network is relatively static and you know the hosts that will
be looked-up, use a local hosts file. Add the database server and
any other common hosts to your /etc/hosts file. Then make sure that
your /etc/svc.conf has "local" as the first source checked for host
information.
hosts=local,bind,yp
2. If your network is too dynamic, or if the hosts that you connect to
are too variable, you could run a caching-only nameserver on the
local host. They aren't hard to setup and your information will
always be current.
Populating your local host file is the simpler of the two solutions,
and I'd advise persuing that unless you have a large number of external
hosts that you need to access. If you do have a large number of external
hosts, who's addresses may change w/o notice, a chaching nameserver may
be a better answer.
Received on Tue Apr 27 1999 - 13:57:09 NZST