Why Is lwresd better than nscd

lwresd was chosen for use on RHEL5 Linux to fix the problems we came across during our daily use and troubleshooting of NSCD. The most important ones are:

lwresd was chosen for use on RHEL5 Linux to fix the problems we came across during our daily use and troubleshooting of NSCD. The most important ones are:

  • your queries avoid the stub-resolver with its slow timeouts and static, sequential queries against forwarders
  • NSCD cannot honour DNS TTLs in the vast majority of cases — all records expire after a fixed interval (which was five minutes on the RHEL3 fleet), causing a storm of queries every five minutes to our servers
  • lwresd will honour the TTL of each record
  • nscd doesn’t follow chained CNAMEs which are becoming an important part of our DNS infrastructure
  • nscd did not cache any data from a reply which contains multiple A records when they are returned from a DNS server (this has been fixed in recent versions of nscd)
  • it’s impossible to create local views or direct some queries to some nameserver, it is possible with lwresd
  • if we need to upgrade nscd because of a bugs (it has bugs actually) we have to update glibc, which is infeasible fleet-wide.
  • lwresd is essentially a full-service BIND9 resolver with all of its round-trip-time and host reachability awareness. nscd doesn’t speak DNS at all. A cache miss in nscd will fallback to the rudimentary glibc stub resolver with its lengthy timeouts and sequential DNS server query strategy
  • lwresd is a real DNS cache; nscd caches only IPv4 address records