Применимость и проверка
Смысл кода протокольный, не привязан к одной ОС. Пример команды подготовлен по руководству BIND dig 9.18.30 . На Windows, macOS и российских Linux системный resolver и утилиты могут отличаться; эта карточка не утверждает проверку всех клиентов.
Не смешивать похожие результаты
| Наблюдение | Значение для следующего шага |
|---|---|
| NXDOMAIN / RCODE 3 | Ответ об отсутствии имени; проверить фактический QNAME, зону, aliases и DNS view |
| NOERROR без нужного RRset | Возможен NODATA: имя существует, требуемого типа записи нет; одного пустого Answer недостаточно для диагноза |
| SERVFAIL / RCODE 2 | Сервер не смог нормально обработать запрос; это другая ветка причин |
| Timeout | DNS-ответ не получен в заданный период; это не NXDOMAIN |
Если есть цепочка CNAME, отрицание может относиться к конечному имени цепочки; необходимо просмотреть ответ целиком. Отрицательные ответы могут кэшироваться, поэтому изменение зоны не обязательно немедленно меняет ответ resolver. Эти различия описывает RFC 2308.
Пример проверки
Сначала сохранить контекст: QNAME, QTYPE, сервер, время/таймзону, источник запроса и полученный status. Пример ниже использует документационный адрес сервера 192.0.2.53: заменить его адресом разрешённого тестового resolver. Он не предназначен для копирования как рабочий публичный DNS.
dig @192.0.2.53 missing.example.test. A +noall +comments +answer +authority +time=2 +tries=1
Точка в конце делает имя полным; +comments нужен для status/flags, +authority — для просмотра отрицательного ответа. Только +short скрывает важные детали. Синтаксис сверялся с руководством dig 9.18.30.
Иллюстрация полей, не вывод dig:
resolver=192.0.2.53
qname=missing.example.test. qtype=A
rcode=3 status=NXDOMAIN
answer_count=0 authority_contains=SOA
Поля и контекст
| Поле | Зачем нужно |
|---|---|
| QNAME / QTYPE | Отличить опечатку, поисковый suffix, A/AAAA и другое требование |
| Server | Установить, кто ответил; системный stub и upstream могут быть разными |
| RCODE / status | Определить ветку диагностики, не выводить её только из текста браузера |
| Flags / sections | Понять контекст ответа; отсутствие authoritative flag у resolver само по себе нормально |
| CNAME / authority SOA / TTL | Разобрать цепочку и возможное отрицательное кэширование |
| Network / DNS view / policy | Внутреннее имя может быть доступно только из нужного контура |
Последовательность диагностики
- Перепроверить полное имя и тип; если имя введено иначе, повторить точный запрос в разрешённой среде.
- Проверить адрес фактически используемого resolver. Для внутреннего имени сравнивать с корпоративной DNS view; публичный DNS не обязан знать внутреннюю зону.
- Если ответ различается по resolver/сети, изучить forwarding, split DNS, VPN и локальную политику. Различие — наблюдение, а не доказанная причина.
- Если resolver и ожидаемая view верны, проверить наличие имени/цепочки в авторитетной зоне и недавние изменения; учитывать negative caching.
- Если DNS-ответ синтезируется политикой фильтрации, искать правило и журнал соответствующего продукта. Не объявлять NXDOMAIN доказательством блокировки или атаки.
Нормальные объяснения: несуществующее тестовое имя, опечатка, устаревшая ссылка. Дополнительной проверки требуют повторяющиеся необычные имена или нарушение ожиданий для внутренней зоны, но для вывода нужны другие данные. Статус браузера DNS_PROBE_FINISHED_NXDOMAIN относится к клиентскому отображению и не добавлен как отдельный подтверждённый код продукта.
Связи
DNS в существующем словаре. 53/TCP и 53/UDP доступны в реестре, SERVFAIL — в отдельном разборе. Ошибки HTTP, SMTP и TLS имеют другие namespace.