Помилки 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 пояснюють походження та строк дії результату.

Як діагностувати DNS

Спочатку перевірте ім’я та query type, потім authoritative answer, після цього — потрібний recursive resolver. NXDOMAIN, SERVFAIL, REFUSED і timeout мають різні причини. Для змін DNS порівнюйте authoritative server із кількома 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. Після цього переходьте до маршруту, портів і прикладного протоколу. Зробіть одну зміну, повторіть вимірювання та порівняйте. Такий порядок зменшує кількість хибних висновків і формує конкретні дані для адміністратора або провайдера. Після усунення проблеми повторіть початковий тест, щоб підтвердити зміну саме потрібного симптому.