DNS_PROBE_FINISHED_NXDOMAIN: как проверить DNS и вернуть доступ к сайту

Домен может быть оплачен, сайт — запущен, а браузер всё равно сообщает DNS_PROBE_FINISHED_NXDOMAIN или «Не удаётся найти IP-адрес сервера». Покупка более мощного VPS здесь не поможет: сначала нужно выяснить, где теряется связь между именем и адресом.

В этой инструкции разберём проверку DNS в Windows и Linux, различия NXDOMAIN и SERVFAIL, старые адреса в кеше и ошибки IPv6. Если домен только подключается впервые, начните с настройки домена для хостинга. Здесь задача другая — найти причину уже возникшей неисправности.

DNS, HTTPS или приложение: определить слой ошибки

Сначала запишите точное имя: example.org, www.example.org и app.example.org — разные DNS-имена. Работоспособность одного не доказывает, что два других настроены.

Что наблюдаем	Что проверять первым
NXDOMAIN, браузер не находит IP	Регистрацию, делегирование, наличие имени в DNS
SERVFAIL	Работу DNS-серверов, делегирование и DNSSEC
IP найден, соединение истекает по времени	Сеть, firewall, порты и службу веб-сервера
Предупреждение о сертификате	Имя в сертификате, срок и цепочку доверия
HTTP 502 или 500	Прокси, приложение и его журналы

DNS не хранит путь /catalog/ и не выбирает порт приложения. Если открывается главная, но не отдельная статья, это обычно уже задача маршрутизации сайта. Для такой проверки пригодится разбор логов ошибок.

Проверить регистрацию и делегирование

В кабинете регистратора убедитесь, что домен действует, не находится в состоянии приостановки и использует правильные NS-серверы. Затем откройте зону именно у того DNS-провайдера, на которого указывают NS. Запись, добавленная в старой панели, не начнёт работать только потому, что она выглядит правильно.

Распространённый сценарий: сайт перенесли на VPS, NS оставили у регистратора, а A-запись изменили в панели хостинга. В интернете продолжает использоваться зона регистратора. Исправлять нужно действующую зону; смена NS целиком для этого часто не требуется.

Перед изменением сохраните текущие записи. Особое внимание уделите MX и TXT: перенос сайта не должен случайно отключить почту, SPF, DKIM или подтверждение сервисов. В руководстве по переносу сайта этот этап связан с проверкой самого приложения.

Посмотреть ответы в Windows

В PowerShell выполните команды, заменив пример своим именем:

Resolve-DnsName -Name example.org -Type A -DnsOnly
Resolve-DnsName -Name example.org -Type AAAA -DnsOnly
Resolve-DnsName -Name example.org -Type NS -DnsOnly
Resolve-DnsName -Name www.example.org -Type CNAME -DnsOnly

Отсутствие AAAA или CNAME само по себе не ошибка. Сайт может работать только по IPv4, а www — иметь собственную A-запись. Важно, соответствует ли ответ вашей схеме.

Чтобы сравнить системный ответ с другим резолвером, укажите сервер явно:

Resolve-DnsName -Name example.org -Type A -Server 1.1.1.1 -DnsOnly
Resolve-DnsName -Name example.org -Type A -Server 8.8.8.8 -DnsOnly

Это диагностический запрос, а не необходимость менять DNS всей операционной системы. В корпоративной сети обращения к внешним резолверам могут блокироваться. Тайм-аут такого запроса ещё не означает, что домен сломан.

Проверить A, AAAA и NS в Linux

На Ubuntu утилита dig входит в пакет dnsutils. Если её нет:

sudo apt update
sudo apt install dnsutils

Для первого разбора полезен ответ с кодом состояния, а не только краткий список адресов:

dig example.org A +noall +answer +comments
dig example.org AAAA +noall +answer +comments
dig example.org NS +short

NOERROR означает, что DNS-запрос обработан успешно. При этом секция ответа может быть пустой: например, имя существует, но AAAA для него не задана. NXDOMAIN означает, что запрошенного имени нет с точки зрения отвечающей DNS-системы. Это отличается от отсутствия одного типа записи.

В учебной проверке на Ubuntu 24.04.5 домен Hostfera вернул A-запись со статусом NOERROR, а заведомо отсутствующий поддомен — NXDOMAIN. Эти два состояния показаны на записи реального сеанса.

Сравнить резолвер с авторитетным сервером

Резолвер может ещё хранить прежний ответ. Авторитетный сервер отвечает за саму зону. Возьмите действующее NS-имя из предыдущей команды и подставьте его вместо ns1.provider.example:

dig @ns1.provider.example example.org A +noall +answer +comments
dig @1.1.1.1 example.org A +noall +answer +comments
dig @8.8.8.8 example.org A +noall +answer +comments

Если авторитетные серверы показывают новый IP, а один резолвер — прежний, вероятно, различается состояние кеша. Если сами авторитетные серверы отвечают по-разному, исправляйте зону или её распространение у DNS-провайдера. Многократная смена A-записи в такой ситуации только усложняет наблюдение.

При запросе к NS проверьте флаг aa в полном ответе: он помогает понять, получен ли авторитетный ответ для запрошенной зоны. Не выбирайте сервер случайно по названию компании — используйте фактическое делегирование своего домена.

Почему изменение не видно сразу

TTL задаёт время хранения ответа в кеше. Снижение TTL после изменения не удаляет уже сохранённый старый ответ: он мог быть получен с прежним, более длинным сроком. Отрицательные ответы тоже кешируются, поэтому только что созданный поддомен иногда продолжает выглядеть отсутствующим у части пользователей.

Не обещайте себе универсальные «15 минут» или «ровно сутки». Смотрите, какой именно ответ устарел, где он получен и какой TTL у него был. Кроме резолвера, информацию могут сохранять браузер, ОС, VPN-клиент и локальная сеть.

В Windows локальный DNS-кеш можно очистить командой Clear-DnsClientCache. На Ubuntu с systemd-resolved — sudo resolvectl flush-caches. Это касается локального устройства. Кеши чужих резолверов эти команды не очищают и ошибочную зону не исправляют.

Отдельно проверить IPv6 и DNSSEC

Если AAAA указывает на старый сервер, часть клиентов попробует IPv6 и получит другую страницу, тайм-аут или неправильный сертификат. Сравните маршруты:

curl -4 -I --max-time 15 https://example.org/
curl -6 -I --max-time 15 https://example.org/

У второй команды должен быть рабочий IPv6 и на устройстве, с которого идёт проверка. Ошибка «Network is unreachable» на клиенте не доказывает неисправность IPv6 сайта. Если IPv6 на сервере не используется, AAAA не должна вести на чужой или прежний адрес.

При SERVFAIL после смены DNS-провайдера проверьте DNSSEC. Несогласованные DS-записи у регистратора и ключи новой зоны могут мешать проверке подписей. Сопоставьте настройки обеих сторон по документации провайдера. Постоянное отключение проверки на устройстве посетителя маскирует проблему, а не решает её.

После исправления проверить сам сайт

Когда имя возвращает нужный адрес, переходите к HTTPS и приложению:

curl -I --max-time 15 https://example.org/
curl -I --max-time 15 https://www.example.org/

Проверьте ожидаемый статус, конечный адрес и сертификат каждого используемого имени. Если DNS ещё распространяется, приложение на новом сервере можно проверить заранее через curl --resolve: подробный порядок есть в статье о проверке до переключения DNS.

В завершение откройте сайт с другой сети и проверьте важную внутреннюю страницу. Полный контроль после запуска поможет не остановиться на одном успешном ответе DNS. Если остаётся ошибка сертификата, переходите к настройке SSL; если сервер отвечает 502 — к диагностике Nginx и приложения.