As I recall, GNU libc doesn't cache DNS results, by default. It can be told to cache results,
but they never expire, and the cache grows without bound. Perhaps it is the lack of
expiration that makes it unfixable, and perhaps the default mode (and impractical optional
mode) that makes it of little concern.
My information might be out of date; has it changed since 1999?
Posted Jul 9, 2008 20:54 UTC (Wed) by nix (subscriber, #2304)
[Link]
I can't see any sign that glibc's internal libresolv or nss-dns layer can
be told to cache anything but DNS server addresses at all. (Of course nscd
can cache DNS responses, and expire them.)
glibc
Posted Aug 5, 2008 4:26 UTC (Tue) by rickmoen (subscriber, #6943)
[Link]
Nathan (ncm) might be thinking of the caching that transpires if you start the nscd
(nameservice
caching daemon). It's commonly used on systems with heavyweight lookup regimes (NIS, NIS+,
LDAP) to prevent system performance from bogging down excessively, by locally caching lookup
of
hosts, users, groups, services, RPC ports, netgroups, etc. but has the drawback that it
ignores TTL
values on host lookups. (That's a sufficient reason to disable host caching in /etc/nscd.conf
.)
The BIND8-derived stub resolver in glibc isn't a huge security risk on most systems despite
its
haplessly failing to randomise UDP source ports, because the result doesn't get cached.
(Thus,
sending it poisoned data in an ADDITIONAL SECTION portion of a recursive DNS response doesn't
do the attacker much good, because the poison gets metaphorically flushed immediately.)
However, such a system with nscd caching hostnames would have a problem. (So, Don't Do That,
Then.)
Rick Moen
rick@linuxmafia.com
glibc
Posted Aug 5, 2008 8:38 UTC (Tue) by nix (subscriber, #2304)
[Link]