Я настроил много серверов в своей компании для работы с NSCD для локального кэширования хостов и для снижения трафика на локальные DNS-серверы, а также для получения более быстрого ответа DNS, когда это возможно.
Я настроил nscd
вот так и используя его только для кеширования хостов:
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
Вы можете видеть, что я настроил положительный TTL на 24 часа.
У меня вопрос, какой TTL используется? Тот, который настроен здесь, или тот, который настроен для каждого домена в DNS?
Я предполагаю, что имеет место более короткий TTL, но я могу ошибаться, не могли бы вы пролить свет на этот вопрос?
Важно отметить, что nscd
действует как кеш для системы распознавания в целом, не специально для поиска DNS, а для всех средств поиска имени.
В результате этого, nscd
исторически имел проблемы с TTL DNS.
Версии glibc nscd
с до 2004-09-15 не работал должным образом с TTL DNS.
Когда это было решено, glibc nscd
все еще имел дело только с DNS TTL если приложение вызвало getaddrinfo
; если приложение называется устаревшим gethostbyname
функции, значения TTL DNS по-прежнему игнорировались.
Насколько я понимаю, сопровождающие glibc наконец прогнулся в glibc 2.8 (2008) и сделали поведение единообразным для всех методов поиска имени. Текущие версии должны использовать TTL DNS независимо от того, как был инициирован поиск.
Смотрите также:
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