Сайт не открывается из-за DNS: 8 причин и решения

Сайт не открывается из-за DNS: 8 причин и решения

Когда браузер показывает ошибку DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL или просто «Не удаётся получить доступ к сайту», проблема почти всегда лежит на уровне DNS. Сайт может быть полностью рабочим на хостинге, но пользователь до него не доходит: резолвер не смог превратить имя домена в IP геолокацию. Такие ошибки критичны для бизнеса — они выглядят как полный простой, хотя серверы в порядке.

В этой статье — 8 самых распространённых причин, по которым DNS перестаёт резолвиться, вместе с пошаговой диагностикой. Мы пройдёмся от локального кэша браузера до цепочки авторитативных серверов, и для каждой причины дадим практические команды и инструменты для проверки.

Что такое «DNS не резолвится»

Любой запрос к сайту начинается с DNS-резолюции: клиент спрашивает у рекурсивного DNS-сервера IP домена, тот рекурсивно опрашивает корневые, TLD и авторитативные серверы, и возвращает A/AAAA-запись. Если на любом из этапов произошёл сбой — ответа не будет, и сайт «не откроется».

NXDOMAIN

Домен не существует в DNS — либо он действительно не зарегистрирован, либо авторитативные серверы вернули такой ответ.

SERVFAIL

Резолвер не смог получить валидный ответ. Часто связано с DNSSEC или недоступностью авторитативных NS.

REFUSED

Сервер отказал в ответе — чаще всего это настройка доступа на авторитативном DNS.

Timeout

Ответа нет вовсе: сеть, firewall или недоступные NS.

8 причин, из-за которых сайт не резолвится

1. Устаревший локальный DNS-кэш

После смены IP или NS браузер и ОС могут держать старую запись до истечения TTL. Пользователь видит 404, «connection refused» или белую страницу.

Проверка:

dig example.com @8.8.8.8 +short
dig example.com @1.1.1.1 +short

Если с публичными резолверами ответ правильный, а у пользователя нет — проблема в локальном кэше.

2. Неправильные или непрописанные NS-записи

Если у регистратора указаны одни NS, а фактически зона хостится на других — клиенты будут уходить в «мёртвые» серверы. Особенно часто случается при миграции с одного провайдера DNS на другой.

dig NS example.com +short
whois example.com | grep -i "name server"

Список NS у регистратора и в DNS-зоне должен совпадать.

3. Просроченный домен

При просрочке регистратор автоматически снимает NS-делегирование. Домен переходит в статус redemption или pendingDelete, и любые запросы возвращают NXDOMAIN. Проверяется через WHOIS Lookup.

4. TTL слишком большой при миграции

Если перед сменой IP или NS вы не понизили TTL (например, оставили 86400), старые записи будут жить у клиентов сутки после переезда. Это типичная причина «у нас уже работает, у клиентов нет».

Подробнее о настройке — в нашем гайде DNS TTL best practices.

5. Ошибки в DNSSEC

Если зона подписана DNSSEC, но DS-запись у регистратора не соответствует актуальному ключу (KSK), валидирующие резолверы вернут SERVFAIL. Такое часто бывает после переноса зоны или смены ключей.

dig example.com +dnssec +multi
dig DS example.com @1.1.1.1 +short

6. Заблокированный DNS-трафик (порт 53)

Корпоративные firewall, гостевой Wi-Fi или некоторые ISP блокируют исходящие запросы на 53/UDP или 53/TCP к сторонним резолверам. Пользователь зависит от локального DNS, и если тот сломан — сайт не откроется.

7. DNS-сервер провайдера недоступен или перегружен

Резолвер ISP может быть временно недоступен или выдавать частичные ответы. Решение — временно переключиться на 1.1.1.1, 8.8.8.8 или 9.9.9.9.

8. Ошибка в зоне: «висящие» CNAME или циклы

CNAME на несуществующую запись, NS-loop, пустая MX-запись с CNAME (что запрещено RFC 2181) — всё это ломает резолюцию. Проверяется полной трассировкой:

dig +trace example.com

Как диагностировать за 5 минут

1. Проверить публичный резолвер. Откройте DNS Lookup и посмотрите A, AAAA, NS, SOA.
2. Сравнить с локальной машиной. В терминале: dig example.com и dig example.com @8.8.8.8. Если ответы разные — проблема локальная.
3. Проверить распространение. Используйте DNS Propagation Checker — он показывает ответы с десятков узлов по миру.
4. Проверить WHOIS и NS. WHOIS Lookup покажет текущих регистратора и NS.
5. Проверить цепочку DNSSEC. DNSViz — визуализатор валидации DNSSEC.

Решения

Сбросить локальный кэш

Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux: sudo systemd-resolve --flush-caches. Подробный гайд — Как очистить DNS-кэш.

Сменить DNS-резолвер

Публичные резолверы — 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9).

Синхронизировать NS у регистратора и провайдера DNS

Зайдите в панель регистратора и проверьте Name Servers. Они должны в точности совпадать с теми, что возвращает dig NS example.com.

Понизить TTL ЗА 48 часов до миграции

Установите TTL = 300 секунд минимум за сутки (лучше 48 часов) до миграции, после переноса вернитесь к обычному значению 3600–86400.

Включить мониторинг DNS

Enterno.io поддерживает мониторинг сайтов DNS Lookup с алертами в Telegram, Email, Slack и вебхуках. Настройка — в разделе Мониторы.

Профилактика

• Используйте двух независимых DNS-провайдеров (secondary DNS) — защита от отказа одного.
• Включите автообновление домена у регистратора — исключит просрочку.
• Настройте мониторинг на NS-delegation consistency.
• Держите документацию по актуальным NS, TTL и DNSSEC-ключам.
• Тестируйте миграции на staging-домене с коротким TTL.

FAQ

Почему сайт открывается у одних и не открывается у других?

Чаще всего это разный TTL-кэш на уровне резолверов ISP. Ждите истечения старого TTL или сменяйте резолвер.

Может ли Cloudflare кэшировать NXDOMAIN?

Да, согласно RFC 2308 любой резолвер кэширует negative responses по значению SOA minimum/TTL.

Что важнее: Glue-записи или NS в зоне?

Glue-записи нужны только когда NS находится в том же домене. Они должны соответствовать A-записям у NS-хостов, иначе резолвер перейдёт в «lame delegation».

Можно ли обойтись без DNSSEC?

Да, но с риском подделки ответа (DNS spoofing). Для критичных сервисов DNSSEC рекомендуется.

Заключение

Большинство «не резолвится» сводится к трём классам ошибок: кэш, NS-делегирование и TTL. Пройдитесь по чек-листу сверху вниз — от локального кэша к авторитативным серверам и WHOIS, — и за 10 минут локализуете причину. Для постоянной защиты настройте мониторинг DNS в Enterno.io: мы проверяем A, AAAA, NS, MX, TXT и CNAME с нескольких регионов и мгновенно присылаем уведомление при любом отклонении.