Проверка DNS записей домена

Состав проверки зависит от назначения домена, но базовый набор почти всегда включает записи A, AAAA, CNAME, MX, TXT, NS и SOA. Запись A указывает IPv4-адрес, по которому открывается сайт или отдельный поддомен. AAAA выполняет ту же функцию для IPv6. Если сервер не поддерживает IPv6, наличие случайной или устаревшей AAAA-записи способно вызвать проблемы у части посетителей.

CNAME создает алиас: поддомен направляется на другое доменное имя. Его часто используют для www, CDN, конструкторов сайтов, аналитики и подтверждения интеграций. Важно убедиться, что CNAME не конфликтует с другими записями для того же имени. Корневой домен обычно нельзя настроить как обычный CNAME, если DNS-провайдер не использует специальные механизмы.

MX определяет серверы, принимающие почту для домена. У записей MX есть приоритет: меньшее число означает более предпочтительный маршрут. Для надежной почты проверяют, что указанные серверы существуют, разрешаются в IP-адреса и соответствуют настройкам почтового провайдера.

TXT-записи хранят SPF, DKIM, DMARC, коды подтверждения и другие служебные значения. При проверке нужно сравнивать значение целиком, включая кавычки, точки, селекторы и ограничения. Для SPF особенно важно, чтобы на одном домене была только одна политика SPF: несколько отдельных SPF-записей могут сделать проверку почты некорректной.

Сначала нужно определить, какие серверы имен являются авторитетными для домена. Это задается NS-записями у регистратора. Затем следует убедиться, что на всех авторитетных серверах размещена одинаковая актуальная зона. Если один сервер имен отдает старые данные, результат проверки у пользователей будет зависеть от того, к какому серверу обратился их резолвер.

SOA-запись помогает оценить состояние зоны. В ней указан основной сервер, контактный адрес администратора, серийный номер и интервалы обновления. После изменения зоны серийный номер должен обновиться. Если используется вторичный DNS, одинаковый серийный номер на основном и вторичных серверах подтверждает, что передача зоны завершилась.

Полезно проверить цепочку делегирования: родительская зона должна направлять домен на корректные NS-серверы, а сами NS-серверы обязаны отвечать за нужную зону. Ошибки делегирования встречаются при смене DNS-провайдера, переносе домена или удалении старой инфраструктуры. Отдельно проверяют glue-записи, если серверы имен расположены внутри проверяемого домена.

Для сайта сопоставьте A и AAAA-записи домена и www с адресами, которые выдал хостинг, балансировщик или CDN. Проверьте, что старые адреса не остались в зоне, а редирект между вариантами домена настроен на уровне веб-сервера. DNS не управляет HTTP-редиректом, но неверная запись может отправить пользователя на другой сервер, где сертификат или сайт отсутствует.

Для каждого используемого поддомена составляют список ожидаемых записей: app, api, mail, ftp, shop, staging и других. Особенно внимательно проверяют тестовые поддомены. Забытые записи могут вести на освобожденный сервер или старый сервис, что создает риск перехвата трафика и утечки данных.

Почтовая диагностика включает MX, SPF, DKIM и DMARC. SPF должен разрешать только реальные источники отправки. DKIM требует существования TXT-записи по имени селектора, а публичный ключ должен совпадать с настройкой отправляющего сервера. DMARC задает политику обработки писем, не прошедших проверки, и адреса отчетов. Некорректный синтаксис или лишние пробелы в этих записях могут снизить доставляемость писем.

После обновления DNS данные распространяются постепенно из-за кеширования. Основной параметр здесь TTL, то есть время жизни записи в кеше резолверов. Пока прежний TTL не истек, часть пользователей и сервисов может получать старый ответ. Поэтому при плановой миграции TTL разумно уменьшить заранее, дождаться обновления кешей, а затем менять адреса.

Нужно отличать распространение изменений от ошибки настройки. Если авторитетный DNS-сервер уже отдает новую запись, но публичные резолверы отвечают старой, чаще всего нужно дождаться истечения TTL. Если разные авторитетные серверы отвечают по-разному, проблема находится в синхронизации зоны. Если новый ответ не появляется даже после ожидаемого времени, проверьте сохранение записи в панели управления, делегирование NS и отсутствие опечаток в имени.

Не следует удалять старый сервер сразу после смены IP. На период распространения он должен продолжать обслуживать запросы либо перенаправлять их на новую инфраструктуру. Это уменьшает риск прерывания работы сайта и почты для пользователей со старыми кешированными значениями.

Распространенная ошибка — запись создана не для того имени. Например, вместо поддомена добавляют запись для корня зоны или наоборот. Также встречаются дубли A-записей с неактуальными адресами, лишние CNAME, неправильный приоритет MX и TXT-значения, скопированные не полностью.

Начинайте исправление с фиксации ожидаемой схемы: какие имена должны существовать, куда они ведут, какие почтовые сервисы разрешены и какие записи необходимы для верификации. Затем сравните эту схему с ответами авторитетных серверов. Изменяйте записи по одной логической группе и документируйте прежние значения, TTL и время внесения правки.

После изменений повторно проверьте ответы авторитетных серверов, затем ответы независимых резолверов. Для критичных сервисов проведите прикладную проверку: откройте сайт по домену, отправьте тестовое письмо, проверьте получение почты и авторизацию подключенных сервисов. Регулярный аудит DNS особенно важен после смены хостинга, почтового провайдера, CDN, регистратора или ответственного администратора.