Как проверить DNS-записи домена
Разбираем, где смотреть DNS-записи, как отличить авторитетный ответ от кешированного и какие ошибки не следует принимать за поломку DNS.
DNS связывает доменные имена с адресами и другими параметрами сервисов. Когда сайт не открывается, письма не доходят или подтверждение владения доменом не проходит, полезно не гадать по сообщению браузера, а посмотреть конкретный ответ DNS. Такая проверка ничего не меняет в зоне: она только читает опубликованные данные.
Самый быстрый вариант - открыть проверку DNS-записей, указать домен без https://, пути и номера порта, затем выбрать нужный тип записи. Для более глубокой диагностики пригодятся dig или nslookup. Важно понимать, какой сервер дал ответ и был ли он авторитетным либо кешированным.
Что именно проверять
Тип записи выбирают по задаче, а не перебирают вслепую:
| Тип | Что обычно содержит | Когда смотреть |
|---|---|---|
A |
IPv4-адрес | Сайт или другой узел не находится по имени |
AAAA |
IPv6-адрес | Ошибка проявляется только у клиентов с IPv6 |
CNAME |
Каноническое имя для псевдонима | Поддомен направлен на внешний сервис |
MX |
Имена почтовых серверов и приоритеты | Не принимается входящая почта |
TXT |
Текстовые данные, в том числе политики и проверки | Не проходит верификация или проверка почтовой политики |
NS |
Авторитетные серверы зоны | Есть подозрение на ошибку делегирования |
SOA |
Служебные параметры зоны | Нужно сравнить версии зоны и параметры кеширования |
Наличие записи ещё не доказывает работоспособность связанного сервиса. Например, корректный A-ответ не означает, что веб-сервер слушает порт 443, а MX не подтверждает, что почтовый сервер примет конкретное письмо.
Проверка через dig
На Linux и macOS часто доступна утилита dig. Она отправляет DNS-запрос и печатает ответ. Команда ниже запрашивает IPv4-адрес зарезервированного для документации домена:
dig example.com AВ секции ANSWER SECTION находятся найденные записи. Число после имени обычно показывает оставшийся TTL в ответе, далее идут класс IN, тип и значение. Строка SERVER сообщает, какой рекурсивный сервер ответил. Флаг aa в заголовке означает authoritative answer, но при обычном запросе к системному резолверу его чаще всего нет.
Краткий вывод удобен для скрипта или визуального сравнения:
dig example.com A +short
dig example.com AAAA +short
dig example.com MX +shortПустой краткий вывод не всегда означает сбой. У имени может не быть записи запрошенного типа. Чтобы различить отсутствие данных, несуществующее имя и сетевую ошибку, посмотрите полный вывод и поле статуса: например, NOERROR с пустым ответом отличается от NXDOMAIN.
Для проверки авторитетного источника сначала запросите NS, затем обратитесь к одному из полученных серверов:
dig example.com NS +short
dig @<authoritative-server> example.com AЗамените заполнитель <authoritative-server> фактическим именем NS. Такой запрос помогает понять, опубликовано ли новое значение в самой зоне. Он не показывает, когда запись исчезнет из всех ранее заполненных кешей. Связанный разбор DNS-кеширования появится в разделе руководств после ручной проверки.
Проверка через nslookup
nslookup обычно доступен в Windows и встречается в других системах. Явно укажите тип:
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.comВ Windows конкретный DNS-сервер можно передать последним аргументом, например nslookup -type=A example.com 192.0.2.53. Адрес 192.0.2.53 здесь относится к диапазону для документации и не является готовым публичным резолвером: в реальной проверке подставляют адрес разрешённого сервера своей организации или провайдера.
Вывод nslookup различается между реализациями, поэтому для автоматической обработки лучше использовать структурированный API или предсказуемый режим dig. Для ручной проверки обе утилиты подходят.
Практический пример: после переноса открывается старый сервер
Предположим, адрес www.example.com изменили, но часть пользователей продолжает попадать на прежний хостинг.
- Проверьте
AиAAAA. СтарыйAAAAнередко остаётся незамеченным, если меняли только IPv4. - Проверьте, не является ли
wwwзаписьюCNAME. Тогда искать конечный адрес нужно и у целевого имени. - Запросите запись непосредственно у каждого авторитетного NS. Если ответы различаются, вероятна несогласованная публикация зоны.
- Сравните авторитетный ответ с ответом вашего обычного рекурсивного сервера. Старое значение только у рекурсивного сервера обычно указывает на кеш.
- Посмотрите TTL. Это верхняя граница обычного времени хранения положительного ответа в конкретном кеше, но не обещание одновременного обновления у всех клиентов.
Если авторитетные серверы уже согласованы, многократное сохранение той же записи в панели регистратора не ускоряет истечение существующих кешей. Локальный браузер, операционная система, корпоративный прокси или приложение тоже могут временно хранить результат независимо от видимого DNS TTL.
Как читать неоднозначные результаты
DNS допускает несколько значений A или AAAA для одного имени. Их порядок может меняться, а ответы могут зависеть от точки запроса. CDN и балансировщики способны возвращать разные допустимые адреса разным сетям. Поэтому различие само по себе не является ошибкой: сверяйте значения с ожидаемой конфигурацией поставщика.
У MX меньшее числовое значение означает более высокий приоритет. Но сервер с большим числом не обязательно неисправен: он может быть резервным. У TXT длинное логическое значение иногда отображается несколькими строками в кавычках; DNS-клиент объединяет фрагменты внутри одной записи по правилам формата. Не следует считать каждый визуальный фрагмент отдельной политикой.
Делегирование проверяют с двух сторон. Родительская зона указывает NS дочернего домена, а сама дочерняя зона публикует свой набор NS. Несовпадение может давать нестабильный результат. При включённом DNSSEC дополнительно важна корректная цепочка DS, DNSKEY и подписей; обычное наличие RRSIG ещё не доказывает успешную валидацию.
Частые ошибки
- В поле вводят полный URL
https://example.com/page, хотя DNS работает с именемexample.com. - Проверяют только
Aи забывают проAAAAили промежуточныйCNAME. - Принимают кешированный ответ публичного резолвера за текущие данные авторитетной зоны.
- Ожидают, что уменьшенный сейчас TTL задним числом сократит срок уже закешированной старой записи.
- Считают любой пустой ответ
NXDOMAIN, не проверяя код состояния. - Публикуют секреты в
TXT. DNS-зона обычно общедоступна; токены подтверждения следует удалять, если поставщик разрешает это после проверки. - Используют случайный сторонний DNS-сервер для конфиденциального внутреннего имени. Запрос раскрывает этому оператору проверяемое имя и всё равно может не видеть внутреннюю зону.
Для первичной диагностики зафиксируйте время, имя, тип записи, использованный сервер и полный ответ. Такой снимок позволяет отличить изменение зоны от различий кеша и полезнее скриншота одной строки. Если нужно проверить сразу несколько характеристик домена, дополните DNS-результат сводным отчётом, но оценивайте каждый сигнал отдельно.
Частые вопросы
Какие DNS-записи проверять в первую очередь?
Начните с записи, связанной с симптомом: A и AAAA для открытия сайта, CNAME для псевдонима, MX для маршрутизации почты, TXT для подтверждений и почтовых политик, NS для делегирования зоны. Затем сравните ответ рекурсивного резолвера с ответом авторитетного сервера.
Почему разные DNS-серверы показывают разные ответы?
Рекурсивные серверы могут хранить версии записи, полученные в разное время, пока не истёк их TTL. Различия также возникают из-за географической маршрутизации, нескольких авторитетных серверов с несогласованными зонами или раздельного DNS для внутренних и внешних клиентов.
Можно ли проверить DNS-записи без установки программ?
Да. Веб-проверка DNS показывает основные типы записей и подходит для быстрой диагностики. Команды dig и nslookup полезны, когда нужно выбрать конкретный сервер, увидеть служебные флаги или повторить проверку из определённой сети.