我已经在我的公司configuration了很多服务器，与NSCD一起工作，以便本地caching主机，以便降低到本地DNS服务器的stream量，并在可能的时候返回更快的DNS响应。
我已经像这样configuration了nscd ，只用它来caching主机：
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
你可以看到我configuration了Positive-TTL为24小时。
我的问题是，TTL是哪一个？ 这里configuration的那个还是DNS中每个域configuration的那个？
我的猜测是，较短的TTL是发生的那个，但是我可能是错的，请问这个问题可以谈一谈吗？
需要注意的是， nscd通常作为parsing器系统的caching，不是专门用于DNS查找，而是所有名称查找的手段。
由于这个原因， nscd在历史上遇到了与DNS TTL有关的问题。
2004-09-15之前的glibc nscd版本没有正确处理DNS TTL。
解决之后， 如果应用程序调用getaddrinfo ，则glibc nscd仍然只处理DNS TTL; 如果一个称为过时的gethostbyname函数的应用程序仍然忽略DNS TTL值。
据我了解，glibc维护者终于在glibc 2.8 （2008） 中崩溃了 ，并使所有名称查找方法的行为保持一致。 无论查询是如何启动的，当前版本都应该使用DNS TTL。
也可以看看：
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