Ошибки DNS: NXDOMAIN, SERVFAIL и REFUSED

Ошибки DNS: NXDOMAIN, SERVFAIL и REFUSED. Практическая статья для диагностики сети и корректной интерпретации результата. Один технический сигнал не описывает всю цепочку, поэтому уровни соединения полезно проверять последовательно.

Как проходит DNS-запрос

Ошибки DNS: NXDOMAIN, SERVFAIL и REFUSED нужно рассматривать по цепочке stub resolver → recursive resolver → delegation → authoritative nameserver. Recursive resolver может ответить из cache, поэтому пользовательский ответ не обязательно получен напрямую от authoritative server. TTL, record type и response code объясняют происхождение и срок действия результата.

Как диагностировать ответ

Сначала проверьте имя и query type, затем authoritative answer и после этого выбранный recursive resolver. NXDOMAIN, SERVFAIL, REFUSED и timeout означают разные состояния. После изменения DNS сравнивайте authoritative data с несколькими resolvers; очистка локального cache помогает только когда stale answer хранится локально.

Контрольный сценарий

Контрольный сценарий: выполните одинаковый запрос к authoritative nameserver и двум recursive resolvers, записав response code, answer и TTL. Если authoritative data уже новые, а один resolver возвращает старое значение, причина обычно в cache. Если authoritative server сам возвращает неверную запись или error, простое ожидание TTL конфигурацию не исправит.

Конкретные примеры и значения

Используйте эти значения как ориентиры при чтении документации и результатов проверки: NXDOMAIN; SERVFAIL; REFUSED; timeout; authoritative vs resolver failure.

NXDOMAIN means the queried name does not exist in the DNS view that answered; SERVFAIL means resolution failed to produce a usable answer; REFUSED means the server declined the operation. A timeout is different again because no valid DNS response arrived within the client’s waiting period.

Типичные причины и ошибки

Частая ошибка — считать один успешный тест доказательством исправности всей цепочки. Доступный IP не гарантирует работу DNS, открытый порт не подтверждает корректный протокол приложения, а высокий результат speedtest не исключает задержку, потери или перегрузку Wi-Fi. NAT, CGNAT, firewall, CDN, Anycast и кеши также меняют наблюдаемую картину и должны учитываться в зависимости от задачи.

Что результат не доказывает

Технический результат имеет границы. Он обычно не устанавливает личность пользователя, владельца устройства или единственную причину сбоя без дополнительных данных. Геолокация IP приблизительна, регистрационные данные могут быть скрыты, а маршруты меняются. Безопасность также нельзя сводить к одному флагу, адресу или статусу. Вывод должен соответствовать именно тому свойству, которое было измерено.

Пошаговая диагностика

Начните с воспроизводимого симптома, затем проверьте локальную конфигурацию, адресацию и DNS. После этого переходите к маршруту, портам и прикладному протоколу. Сделайте одно изменение, повторите измерение и сравните. Такой порядок уменьшает число ложных выводов и формирует конкретные данные для администратора или провайдера. После устранения проблемы повторите исходный тест, чтобы подтвердить изменение именно наблюдаемого симптома.