Как проверить DNS домена и найти ошибки в настройках

DNS — это распределенная система, которая преобразует понятное человеку доменное имя в технические данные. Когда пользователь открывает сайт, его устройство сначала запрашивает DNS-запись, получает IP-адрес сервера и только потом подключается к нему. Аналогично почтовые серверы используют DNS, чтобы понять, куда доставлять сообщения для конкретного домена.

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

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

Для обычного сайта основное значение имеют записи A и AAAA. Запись A указывает IPv4-адрес, а AAAA — IPv6-адрес. Если сервер не использует IPv6, ошибочная AAAA-запись способна вызвать проблемы у части посетителей: их устройства могут пытаться подключиться по неработающему адресу.

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

Для почты проверяют MX-записи: они определяют серверы приема писем и порядок попыток доставки. Чем меньше числовой приоритет, тем выше предпочтение сервера. Также необходимы TXT-записи, в которых размещают параметры SPF, DKIM и DMARC. Они помогают подтверждать легитимность почтовых отправителей и снижают риск попадания писем в спам.

Записи NS определяют авторитетные DNS-серверы домена. Именно они являются источником актуальной зоны. Запись SOA содержит служебные параметры зоны, включая серийный номер. При внесении изменений серийный номер должен обновляться, иначе вторичные серверы могут не получить новую версию данных.

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

Особое внимание требуется при использовании собственных NS-серверов. Если их имена находятся внутри проверяемого домена, должны быть корректно настроены служебные адреса для таких серверов. Без них рекурсивные резолверы могут не суметь найти DNS-инфраструктуру домена.

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

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

Задержка после изменения DNS связана с кешированием. У каждой записи есть TTL — время жизни в секундах. Пока TTL не истек, резолверы и устройства могут использовать сохраненное старое значение. Поэтому замена IP-адреса сайта не всегда становится заметной немедленно.

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

Не все задержки вызваны распространением данных. Иногда новое значение не появляется из-за ошибки в зоне, неверного формата записи, отсутствия сохранения в панели или неправильной делегации. Также локальный компьютер, браузер, маршрутизатор или корпоративная сеть могут хранить собственный кеш. Для точной диагностики важно сравнить ответы из разных сетей.

Одна из частых проблем — неверный IP-адрес в A-записи. Она проявляется как открытие старого сайта, ошибка соединения или попадание на чужой сервер. Нужно сверить адрес с параметрами текущего хостинга и убедиться, что запись задана для корневого имени и необходимых поддоменов.

Другая ошибка — конфликт между CNAME и другими записями. Если имя объявлено псевдонимом, для него не следует одновременно создавать A, MX, TXT или иные обычные записи. Следует выбрать корректную структуру: либо имя указывает на адрес напрямую, либо является алиасом другого имени.

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

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