Когда я бегу dig example.com ответ приходит с SERVER: 192.168.0.1, даже при последующих запусках. Это означает, что DIG всегда выполняет сетевой вызов для разрешения записи DNS.
Я (скорее неосознанно) предположил, что моя ОС будет кэшировать запись DNS в соответствии со своим TTL, и что DIG будет использовать этот кеш.
DIG игнорирует TTL / не использует кеши по умолчанию? Если да, как я могу заставить DIG использовать кеш и соблюдать TTL?
Фон / проблема X-Y:
Я хочу способ быстро разрешить записи DNS TXT для сценария nginx, который я пишу. Сценарий будет маршрутизировать запросы на основе содержимого этих записей TXT, поэтому я хотел бы, чтобы какой бы метод я ни использовал, чтобы соблюдать TTL и при необходимости использовать локально кэшированные записи.
dig (поиск информации о домене), как объясняется в руководстве, является гибким инструментом для опроса DNS-серверов, он не запрашивает и не использует ваш локальный кеш DNS (и / или hosts file), но напрямую запрашивает сервер имен, на который вы указываете. По умолчанию это будут единицы из /etc/resolv.conf.
Чтобы использовать кеш DNS вашей системы из командной строки, используйте getent hosts [ip-address | hostname] или в скриптах / коде используйте родную версию man 3 gethostbyname системный вызов.
По общему признанию, это не поможет вам ни в чем, кроме A AAAA или PTR записи.
В dig вывод метки СЕРВЕРА - это ip-адрес имени сервер dig использует, у которых никогда не будет TTL ...
dig ANY www.google.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27695
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 173 IN A 216.58.212.132
;; AUTHORITY SECTION:
google.com. 146915 IN NS ns2.google.com.
google.com. 146915 IN NS ns3.google.com.
google.com. 146915 IN NS ns1.google.com.
google.com. 146915 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 145115 IN A 216.239.34.10
ns1.google.com. 145115 IN A 216.239.32.10
ns3.google.com. 145115 IN A 216.239.36.10
ns4.google.com. 145115 IN A 216.239.38.10
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) <========== My Name SERVER is localhost
;; WHEN: Tue Aug 30 22:51:26 2016
;; MSG SIZE rcvd: 184
Я запускаю свой собственный кэширующий DNS-сервер локально, а не использую публичный преобразователь ISP или Google (8.8.8.8), в основном для spamassassin, который имеет то преимущество, что он локален, но кеш не предварительно заполняется / заполняется другими пользователями. .
По сути, это вопрос решателя ОС, но вы не указали операционную систему. поскольку dig упоминается, я предполагаю, что мы здесь работаем с некоторой разновидностью UNIX.
Операционные системы на основе UNIX не реализуют кэш DNS в самом ядре. Есть несколько тем, которые необходимо обобщить, прежде чем мы перейдем к тому, как это на самом деле реализовано.
Вызовы библиотеки преобразователя обычно осуществляют поиск с помощью переключателя службы имен (NSS), модульной системы для определения используемых источников данных и порядка, в котором они выполняются. Вы можете найти список этих стеков модулей в /etc/nsswitch.conf. Для справки, нас здесь интересует hosts.
Не рекомендуется играть с hosts вход в /etc/nsswitch.conf если вы действительно не знаете, что делаете. Переупорядочивание этих модулей может привести к неприятным вещам, например, к DNS, с которым обращались до /etc/hosts файл!
Перед просмотром стека модулей NSS проверяет наличие запущенного nscd сокет и пытается запросить его. Если nscd настроен для поддержки кеша для рассматриваемой базы данных NSS, возможно, что запись, кэшированная nscd будут возвращены без консультации с модулями NSS. Большинство известных мне дистрибутивов Linux не включить кеширование hosts база данных по умолчанию, и /etc/nscd.conf должны быть настроены.
При этом следует отметить, что многие администраторы считают "запас" nscd демон быть ненадежным, по крайней мере, под Linux. Существует как минимум одна альтернативная реализация. Ваш пробег может отличаться.
Зная вышесказанное, порядок поиска в базе данных хостов работает в следующем порядке:
nscd (если запущен, его сокет присутствует и кеширование хостов включено)/etc/nsswitch.confЭто подводит нас к тому, где dig попадает в это уравнение. Вы можете в значительной степени сослаться на весь ответ HBrujin (dig не использует NSS, только разговаривает по TCP / IP), но загвоздка в том, что для NSS вообще нет кеша, если только 1) nscd работает, и 2) он настроен на кэширование hosts база данных.
Сложность обеспечения кэширования DNS в NSS обычно является причиной того, что большинство администраторов выбирают «более простое» решение - запуск собственного рекурсивного DNS-сервера. Вам не нужно ничего знать о NSS. Просто укажите /etc/resolv.conf в вашем новом блестящем кэше DNS, и пусть он скроет от вас зло NSS. (по крайней мере, пока вам не понадобится узнать, как работает интеграция LDAP)