1. Сохраните полный DNS-контекст
Запишите полное имя, тип и класс запроса, resolver, время и точку клиента. Здесь 2 означает DNS RCODE SERVFAIL, а не DNS TYPE2 или номер порта. Ответ с ошибкой отличается от отсутствия ответа. Реальные версии resolver и клиента ещё нужно установить; пример команды документально привязан к dig 9.18.30.
2. Найдите уже выполненный обмен
Предпочтительно начните с сохранённого вывода клиента, DNS-журнала или пассивного наблюдения за нужный период. dig выполняет новый читающий запрос к разрешённому серверу и может показать уже другое состояние; он не воспроизводит прошлое автоматически. Не подставляйте внешние имена и адреса без рабочего контекста. Сохраните целиком заголовок, вопрос, ответивший сервер и время.
3. Прочитайте результат
В примере resolver вернул SERVFAIL для A-запроса app.example.invalid. Это учебное имя и вымышленный ID34011. Пустая секция ответа сама по себе не означает NXDOMAIN. Не извлекайте причину из номера ID: он служит сопоставлению конкретного обмена и переиспользуется. Для полного анализа нужны недостающие сведения о сервере, флагах и фактическом времени запроса.
4. Постройте проверяемые гипотезы
Код показывает неспособность сервера обработать запрос, но не выбирает между проблемой разрешения, доступом к upstream, валидацией и локальной конфигурацией. Эти варианты проверяются по журналу выбранного resolver и его зависимостям. Сначала уточните, ошибка относится к одному имени, типу или широкому набору запросов. Не отключайте DNSSEC и не меняйте resolver только ради исчезновения симптома.
5. Сопоставьте соседние сведения
Найдите соответствующий запрос на resolver, а при наличии — цепочку обращения к авторитетным серверам. Сравнивайте одинаковые QNAME/QTYPE, временное окно и сетевой контекст; ответы разных DNS views могут быть несопоставимы. Новый успешный ответ означает текущее состояние, а не опровержение старой ошибки. В выводе укажите отдельно подтверждённый ответ и ещё не установленную причину.
6. Если SERVFAIL не воспроизводится
Проверьте временную разницу, кеш, resolver, клиентскую сеть и точное написание имени. Возможно, сохранилось только сообщение приложения без DNS-ответа; тогда нельзя уверенно присвоить RCODE. Если нет серверного журнала, отметьте ограничение и сохраните клиентские данные. Отсутствие нужной строки в ограниченном периоде не подтверждает исправность всей DNS-цепочки.