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