Для обычных поисков DNS можно использовать Dig, чтобы получить ответ, включая оставшийся TTL для записи DNS. Если этот ответ из кеша, TTL будет «отсчитывать» до следующего авторитетного запроса и оставшееся время до появления этого запроса (как указано в этом вопросе: Проверьте оставшийся TTL для сервера имен).
Как я могу получить соответствующее «оставшееся время» для записи с отрицательным кешем? Ответом по определению является «NXDOMAIN» или несуществующий домен; похоже, что с этим ответом не связано никакого TTL, кроме записи SOA (максимально возможное значение времени).
У меня также есть доступ к серверу [BIND 9] напрямую, поэтому способы получить эту информацию напрямую из кеша также приветствуются, хотя я надеюсь, что для этого есть способ на основе запросов.
Не существует способа получить состояние сервера на основе запроса. Клей, таймеры отрицательного кэша и т. Д. Необходимо выгружать из памяти с помощью rndc dumpdb команда.
\- отрицательно кэшируются. \-A, \-AAAA, и т.д.\-ANY указывает на истинное NXDOMAIN. Никакие записи не живут рядом или ниже этого объекта.Вышеизложенное может сбить с толку, если вы не знакомы с концепцией NODATA перед. (RFC 2308) Это означает ответ NOERROR с 0 ответами, в отличие от NXDOMAIN. NXDOMAIN указывает, что записей с таким именем вообще не существует.
Пример отрицательных кэшированных записей:
test1.example.com. 442 \-ANY ;-$NXDOMAIN
test2.example.com. 352 \-AAAA ;-$NXRRSET
Автоматический синтаксический анализ этого файла не для слабонервных, особенно когда имя метки опущено из-за повторения.
Во-первых, TTL для NXDOMAIN должен передаваться через запись SOA в AUTHORITY SECTION ответа. Смотрите мой ответ на Как долго обычно длится отрицательное кеширование DNS? для подробностей.
Что касается вопроса о том, что при последующих запросах TTL уменьшается. Я считаю, что это деталь реализации DNS-сервера.
В ходе тестирования я заметил, что некоторые рекурсивные серверы имен не возвращают AUTHORITY SECTION с записью SOA с уменьшающимся TTL для последующих запросов, тогда как другие делают.
Например, распознаватель облачных бликов (обратите внимание на уменьшение значения TTL):
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 674 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
$ dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 668 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
В то время как преобразователь по умолчанию в AWS VPC ответит разделом полномочий только на первый запрос:
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 300 IN SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0
Обратите внимание, что полномочный сервер всегда должен возвращать полный TTL, который должен быть меньше значения поля SOA.MINIMUM и TTL самой записи SOA. Вы увидите только уменьшение TTL в ответах от рекурсивного (кэширующего) сервера имен.
Также обратите внимание, что при запросе рекурсивных серверов вы часто будете сталкиваться с балансировщиком нагрузки, и, следовательно, вы получите разные ответы в зависимости от того, на каком сервере с балансировкой нагрузки вы случайно попали.