Проверка DNS сайта: записи, делегирование и причины недоступности
DNS связывает доменное имя с IP-адресом и другими техническими параметрами. Ошибка на этом уровне может сделать сайт недоступным ещё до установления HTTP-соединения. Поэтому проверка DNS сайта начинается не с кода ответа веб-сервера, а с цепочки делегирования, авторитетных серверов имён и фактических значений ресурсных записей.
Ниже приведён самостоятельный алгоритм диагностики для владельца сайта, администратора или разработчика. Он помогает отделить проблемы DNS от ошибок хостинга, HTTPS и приложения.
Что именно происходит при DNS-разрешении
Когда пользователь открывает домен, DNS-резолвер ищет ответ последовательно. Сначала определяется зона верхнего уровня, затем серверы имён домена, после чего у авторитетного сервера запрашивается нужная запись. Результат может быть взят из кеша, если срок жизни записи ещё не истёк.
Для сайта обычно важны следующие типы записей:
- A — связывает имя с IPv4-адресом;
- AAAA — указывает IPv6-адрес;
- CNAME — направляет имя на другое доменное имя;
- NS — определяет авторитетные серверы имён зоны;
- SOA — содержит служебные параметры зоны и её серийный номер;
- CAA — ограничивает центры сертификации, которым разрешено выпускать сертификаты для домена;
- MX и TXT — важны преимущественно для почты и подтверждения владения, но обычно не определяют доступность веб-страницы.
Для корневого имени example.ru чаще используется A или AAAA. Поддомен www.example.ru может иметь собственный адрес либо CNAME на основное имя. Проверять их нужно раздельно: рабочий корневой домен не гарантирует правильный ответ для www.
Диагностический алгоритм
1. Зафиксируйте симптом и проверяемое имя
Запишите точное имя, протокол и наблюдаемую ошибку. Домены example.ru, www.example.ru и api.example.ru — разные DNS-имена. Сообщения NXDOMAIN, SERVFAIL и тайм-аут дают разные направления поиска.
NXDOMAIN означает, что запрошенного имени, по мнению отвечающей DNS-системы, не существует. SERVFAIL указывает, что резолвер не смог получить корректный ответ: например, из-за недоступности серверов имён, ошибки DNSSEC или повреждённой конфигурации зоны. Тайм-аут чаще связан с сетевой фильтрацией или неотвечающим DNS-сервером.
2. Проверьте публичный ответ через несколько резолверов
dig example.ru A
dig @1.1.1.1 example.ru A
dig @8.8.8.8 example.ru A
dig example.ru AAAA
dig www.example.ru CNAMEСравните статус запроса, секцию ответа, адреса и TTL. Разные результаты у публичных резолверов могут появляться во время смены записей, но также указывать на рассинхронизацию авторитетных серверов или устаревший кеш.
В Windows можно использовать nslookup example.ru или PowerShell-команду Resolve-DnsName example.ru. Для базовой проверки важен не выбор утилиты, а возможность увидеть тип записи и сервер, от которого получен ответ.
3. Проследите делегирование от корневой зоны
dig +trace example.ru
dig example.ru NS
dig example.ru SOAdig +trace показывает путь от корневых серверов к зоне домена. Убедитесь, что реестр доменной зоны делегирует домен на те NS, которые действительно обслуживают актуальную зону. Записи NS у родительской зоны и внутри самой зоны должны быть согласованы.
Если сервер имён расположен внутри проверяемого домена, например ns1.example.ru, родительской зоне могут потребоваться glue-записи с его IP-адресом. Без них возникает циклическая зависимость: чтобы найти сервер имён, сначала нужно разрешить имя в зоне, обслуживаемой этим же сервером.
4. Опросите каждый авторитетный сервер напрямую
dig @ns1.dns-provider.example example.ru A
dig @ns2.dns-provider.example example.ru A
dig @ns1.dns-provider.example example.ru SOA
dig @ns2.dns-provider.example example.ru SOAВсе заявленные NS должны отвечать авторитетно и возвращать согласованный набор записей. Сравните флаг aa, A/AAAA/CNAME и серийный номер SOA. Разные номера SOA могут быть нормальны лишь кратковременно при обновлении вторичных серверов; устойчивое расхождение означает, что часть пользователей получает другую версию зоны.
5. Проверьте цепочку CNAME и конечный адрес
CNAME должен приводить к имени, которое разрешается в A или AAAA. Цикл, опечатка или удалённая целевая запись оборвут разрешение. Не следует размещать CNAME на одном имени вместе с A, MX, TXT и другими обычными записями: по модели DNS псевдоним не должен одновременно содержать независимые данные.
6. Учтите TTL и кеширование
После изменения записи старое значение может оставаться у рекурсивных резолверов до окончания прежнего TTL. Отсчёт определяется значением, действовавшим до изменения, а очистка локального кеша не очищает кеш провайдера. Также кешироваться может отрицательный ответ о несуществующем имени.
Фраза «DNS ещё распространяется» сама по себе ничего не доказывает. Нужно сравнить ответы авторитетных серверов с ответами рекурсивных резолверов. Если авторитетные NS уже согласованы, а отдельный резолвер возвращает старые данные с уменьшающимся TTL, причина действительно похожа на кеш.
Проверяемые критерии
| Проверка | Нормальный результат | Признак проблемы |
|---|---|---|
| Делегирование | Родительская зона указывает на действующие NS | Указаны старые, ошибочные или недоступные серверы |
| Авторитетность | Каждый NS отвечает за домен с флагом aa |
Тайм-аут, отказ или неавторитетный ответ |
| Согласованность | NS возвращают одинаковые записи и актуальную SOA | Разные адреса либо устойчиво разные версии зоны |
| A и AAAA | Адреса принадлежат ожидаемой инфраструктуре | Старый IP, пустой ответ или нерабочий IPv6 |
| CNAME | Цепочка завершается существующим адресом | Цикл или ссылка на отсутствующее имя |
| Публичные резолверы | Ответы сходятся после истечения TTL | Долговременное расхождение или SERVFAIL |
Типовые причины недоступности
- Домен делегирован на старого DNS-провайдера. Записи изменены в новой панели, но реестр продолжает направлять запросы на прежние NS.
- Зона не создана на одном из серверов. Один NS отвечает правильно, второй возвращает ошибку или старые данные, поэтому сбой проявляется не у всех пользователей.
- Удалена A-запись корневого домена. При этом
wwwможет продолжать работать как отдельное имя. - Остался неверный AAAA-адрес. Клиенты с IPv6 пытаются подключиться к нему, хотя IPv4-версия доступна.
- В CNAME допущена ошибка. Целевое имя удалено, написано неверно или образует цикл.
- Сломана валидация DNSSEC. У родительской зоны опубликована DS-запись, которая не соответствует ключам текущей зоны. Валидирующие резолверы тогда возвращают
SERVFAIL. - DNS-сервер доступен не по всем путям. Фильтрация UDP или TCP на порту 53, проблемы IPv6 либо сетевые ограничения вызывают выборочные тайм-ауты. Крупные ответы могут потребовать перехода с UDP на TCP.
- Ожидается мгновенное обновление кешей. Запись исправлена авторитетно, но часть резолверов ещё хранит предыдущее значение в пределах TTL.
Граница DNS-проверки
Успешное разрешение имени подтверждает только то, что DNS возвращает пригодный адрес или корректную цепочку псевдонимов. Оно не доказывает, что веб-сервер принимает соединения, выдаёт нужный HTTP-статус, использует подходящий TLS-сертификат или что приложение работает без ошибок.
Если A/AAAA-записи получены, авторитетные серверы согласованы, а соединение всё равно не устанавливается, дальнейшая диагностика должна перейти к маршруту, портам 80 и 443, настройке виртуального хоста и HTTPS. Ответы 404, 500 или 503 уже поступают по HTTP и сами по себе не являются DNS-ошибками.
Проверка из одной сети тоже не отражает состояние для всех пользователей. Локальный файл hosts, корпоративный DNS, VPN или кеш операционной системы могут подменять публичный результат. Поэтому вывод желательно подтверждать прямым опросом авторитетных NS и несколькими независимыми публичными резолверами.
Краткий итог
Надёжная проверка DNS сайта строится сверху вниз: уточнить имя, проверить публичный ответ, проследить делегирование, опросить каждый авторитетный NS, сравнить SOA и ресурсные записи, затем учесть TTL и DNSSEC. Такой порядок позволяет отличить ошибку зоны от кеширования и не смешивать DNS-разрешение с HTTP, сертификатами и серверными сбоями приложения.
После восстановления публичного доступа полезно оценить страницу шире. SiteVisor проверяет публичный URL без доступа к CMS и анализирует технические, SEO/GEO и конверсионные сигналы. Запустить бесплатную проверку можно после того, как домен стабильно разрешается и страница доступна извне.