Кэширующий DNS возвращает SERVFAIL для NS-записи, но dig +trace не согласен?

Question

Кэширующий DNS возвращает SERVFAIL для NS-записи, но dig +trace не согласен?

Этот вопрос похож, но не раскрывает запутанный случай NS запись не может быть получена.

Одна из наших сред кэширования DNS (RHEL 5.8, BIND 9.3.6-20.P1.el5_8.4) перестала возвращать какие-либо полезные данные для зоны. Обычно такая проблема оказывается устаревшей NS или склеить запись, но в данном конкретном случае я не могу даже получить кеш для отчета NS запись для зоны.

dig @mycache somedomain NS возвращается SERVFAIL, Нет записей сервера имен, кэшированных вообще.
dig +trace показывает исправный путь делегирования, при этом конечный сервер имен возвращает ответ. Запуск вручную dig запрос к окончательному серверу имен возвращает действительный NS запись, соответствующая A запись существует и согласуется с клеем и т. д.

Что дает? Почему нет NS запись для меня, чтобы получить из кеша DNS, даже не плохой?

4

domain-name-system bind glue-record

Источник

Andrew B 29 мар '13 в 05:10

1 ответ

Решение

Другие вопросы по тегам domain-name-system bind glue-record

Andrew B 29 мар '13 в 05:10 2013-03-29 05:10 · Accepted Answer · 2013-03-29 05:10

Если нет авторитетного ответа для NS запись, то кешировать нечего, кроме неспособности определить полномочия. Это то, что было кэшировано, и информация сервера в памяти о хромых серверах имен не может быть получена клиентом DNS. (или, скорее, это так близко, как вы собираетесь получить)

Обычно вы можете определить проблему с устаревшими записями сервера имен, сравнив NS запись в кеш на то, что вы найдете в интернете, но в этом случае нет авторитетного NS запись в кеш. Клеевые записи сами по себе не являются авторитетными; без авторитетного ответа просто нет авторитетного сервера имен.

Здесь обычно происходит одна из двух вещей:

dig +trace получает устаревший ответ для промежуточного сервера имен из вашего локального кэша, и в настоящий момент действительно происходит проблема. Я рассказал об этом поведении в другом вопросе.
Обнаружен сервер кэширования NXDOMAIN или же SERVFAIL при поиске склеенных записей, чтобы найти авторитетный сервер имен, и это событие было кэшировано. Даже если проблема была исправлена или клей был указан где-то еще, сервер имен не будет пытаться запросить его снова, пока не истечет внутренний таймер. Запрос очистки кеша для рассматриваемой зоны обычно сбрасывает ее.

Последний случай обычно является виновником. Если вы хотите быть абсолютно уверенным, возможно, вы сможете сбросить кэш времени выполнения вашего сервера имен и просмотреть клей в памяти. (т.е. BIND rndc dumpdb) Имейте в виду, что это очень дорогая операция, если вы не можете ограничить объем дампа одной зоной и, как правило, чего-то, чего следует избегать в сценариях с высокой нагрузкой.