DNS – NSCD TTL vs DNS TTL, Which One Is Stronger

domain-name-systemttl

I've configured many servers in my company to work with NSCD for local caching of hosts and in order to lower traffic to the local DNS servers as well as return a quicker DNS response when possible.

I've configured nscd like so and only using it for caching hosts:

logfile                 /var/log/nscd.log
debug-level             9
server-user           nscd 

paranoia                no

enable-cache            hosts           yes
#positive-time-to-live   hosts           3600
positive-time-to-live   hosts           86400
negative-time-to-live   hosts           20
suggested-size          hosts           211
check-files             hosts           yes
persistent              hosts           yes
shared                  hosts           yes
#max-db-size             hosts   67108864
max-db-size             hosts   536870912

You can see that I've configured Positive-TTL to 24 hours.

My question is, which TTL is the one used? The one which is configured here or the one which is configured per domain in the DNS?

My guess is that the shorter TTL is the one that takes place but I could be wrong, can you please shed some light on this matter?

Best Answer

It's important to note that nscd acts as a cache for the resolver system in general, not specifically for DNS lookups but all means of name lookups.
As a result of this, nscd has historically had issues dealing with the DNS TTLs.

Versions of glibc nscd from before 2004-09-15 did not deal properly with DNS TTLs.
When that was resolved, glibc nscd still only dealt with DNS TTLs if the application called getaddrinfo; if an application called the obsolete gethostbyname functions the DNS TTL values were still ignored.

To my understanding the glibc maintainers finally caved in glibc 2.8 (2008) and made the behavior consistent across all the name lookup methods. Current versions should use the DNS TTLs regardless of how the lookup was initiated.

See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335476
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669304
https://sourceware.org/ml/libc-alpha/2008-04/msg00050.html
https://sourceware.org/bugzilla/show_bug.cgi?id=4428
http://udrepper.livejournal.com/16362.html