Как получить DNS-записи домена
DNS-записи домена показывают, куда направляется сайт, где работает почта, какие сервисы подтверждены и какие правила безопасности настроены. Проверка DNS нужна при переносе сайта, подключении почты, выпуске сертификата, настройке поддоменов и поиске ошибок доступа. Получить сведения можно через системные команды, специализированные сервисы или панель управления доменом.
Важно учитывать, что DNS не хранит всю информацию в одном месте: разные типы записей отвечают за разные задачи. Поэтому для полной диагностики следует проверять несколько типов записей и сравнивать ответ авторитетных DNS-серверов с данными, которые видит обычный пользователь.
Какие DNS-записи можно получить
Основной тип записи для сайта — A. Он связывает доменное имя с IPv4-адресом сервера. Если ресурс доступен по современному IPv6, используется запись AAAA. Для поддомена часто применяют CNAME: он указывает не на IP-адрес, а на другое доменное имя, которое затем разрешается отдельно.
Почтовая инфраструктура определяется записями MX. В них указаны серверы, принимающие почту для домена, и их приоритеты: чем меньше число, тем выше приоритет. Записи TXT содержат текстовые параметры. Чаще всего в них размещают данные для подтверждения владения доменом, правила SPF, ключи DKIM и политику DMARC.
Записи NS показывают авторитетные DNS-серверы зоны. Именно на них публикуются актуальные настройки домена. SOA содержит служебные параметры зоны: основной сервер, контактный адрес администратора, серийный номер и интервалы обновления. Также встречаются SRV для отдельных сетевых сервисов, CAA для ограничения центров сертификации и PTR для обратного сопоставления IP-адреса с именем.
Способы проверить DNS-записи домена
Самый доступный вариант — использовать консольные утилиты операционной системы. Они позволяют запросить конкретный тип записи или получить расширенный ответ от выбранного DNS-сервера. Такой подход удобен для технической диагностики: можно увидеть значения, время жизни записи, цепочку делегирования и возможные ошибки ответа.
В графических онлайн-проверках достаточно ввести домен и выбрать нужный тип записи. Это удобно, когда команды недоступны или нужно быстро сравнить результаты из разных географических точек. Однако данные таких инструментов могут быть закэшированы, поэтому при критичных изменениях лучше сверять ответ с авторитетными серверами зоны.
Третий способ — открыть панель регистратора либо DNS-хостинга. Там отображается исходная конфигурация зоны, которую редактирует владелец домена. Этот вариант не заменяет внешний запрос: запись может быть сохранена в панели, но ещё не распространиться по сети, либо домен может использовать сторонние NS-серверы.
Как правильно читать результат проверки
При анализе ответа сначала убедитесь, что проверяется нужное имя. Запись для основного домена и запись для поддомена — разные объекты. Например, настройки для почты обычно относятся к корню домена, а запись сайта может быть задана отдельно для имени с приставкой www или для другого поддомена.
Обратите внимание на TTL — время жизни записи в секундах. Оно определяет, как долго промежуточные DNS-серверы и устройства могут хранить ответ в кэше. Большой TTL снижает количество запросов, но замедляет применение изменений. Малый TTL помогает быстрее переключить сайт или почту, однако не отменяет уже существующий кэш у части пользователей.
Для MX важно проверять не только список почтовых узлов, но и наличие A или AAAA-записей у каждого указанного имени. Для CNAME нужно проследить всю цепочку до конечной A или AAAA-записи. Если цепочка слишком длинная, содержит цикл или заканчивается отсутствующим именем, сайт либо сервис может не открываться.
TXT-записи необходимо читать целиком. Длинные значения иногда выводятся частями, но логически составляют одну строку. При проверке SPF смотрят на разрешённые источники отправки писем, а для DKIM и DMARC — на корректность селектора, ключа и политики. Несколько противоречивых SPF-записей для одного домена могут привести к ошибке проверки почты.
Проверка делегирования и авторитетных серверов
Если DNS-записи не находятся или возвращаются разные значения, начните с NS. Регистратор хранит сведения о том, какие серверы обслуживают домен, а сами авторитетные серверы содержат зону. Несовпадение этих данных означает проблему делегирования: изменения могут быть внесены не туда, где фактически обслуживается домен.
Полезно запросить записи напрямую у каждого авторитетного сервера. В нормальной ситуации они должны выдавать одинаковую актуальную информацию. Если один сервер отвечает старой зоной, не отвечает вовсе или возвращает ошибку, пользователи могут периодически видеть недоступность сайта и проблемы с доставкой почты.
При переносе DNS-сервиса сначала создают полную копию зоны на новых NS, затем меняют делегирование у регистратора. До переключения стоит снизить TTL у важных записей и проверить A, AAAA, MX, TXT, CNAME, CAA и записи поддоменов. После смены NS нельзя сразу удалять старую зону: некоторое время отдельные резолверы могут обращаться к прежним серверам.
Типичные ошибки при получении DNS-записей
Распространённая ошибка — ожидать мгновенного обновления после изменения записи. Новая конфигурация может появиться на авторитетном сервере сразу, но сохранённые ответы будут действовать до окончания TTL. Иногда задержка связана с настройками провайдера, локальным кэшем устройства или ошибками в делегировании.
Другая проблема — путать доменную зону с настройками веб-хостинга. Наличие A-записи подтверждает направление имени на IP-адрес, но не гарантирует, что на сервере настроен нужный сайт, открыт порт или установлен сертификат. Аналогично корректная MX-запись не означает, что почтовый сервер принимает сообщения и проходит проверки аутентификации.
Не стоит публиковать в DNS секретные данные: пароли, токены доступа, закрытые ключи и внутренние служебные сведения. Большинство DNS-записей доступны публично. Перед изменением зоны сохраняйте текущие значения, фиксируйте время правок и проверяйте результат как минимум по авторитетному серверу и через обычный рекурсивный резолвер.