Как найти DNS-записи домена

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

• A — указывает IPv4-адрес, на который направлен домен или поддомен.
• AAAA — содержит IPv6-адрес ресурса.
• CNAME — задаёт псевдоним, перенаправляя имя на другой домен.
• MX — определяет серверы, принимающие электронную почту для домена.
• TXT — хранит текстовые параметры, включая SPF, DKIM, DMARC и коды подтверждения сервисов.
• NS — показывает авторитетные серверы имён, которые обслуживают DNS-зону.
• SRV — используется отдельными службами для указания хоста, порта, приоритета и веса.
• CAA — ограничивает центры сертификации, которым разрешено выпускать сертификаты для домена.

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

Самый удобный способ найти записи — открыть личный кабинет регистратора домена, хостинг-провайдера или DNS-сервиса. Обычно нужный раздел называется «DNS-зона», «Управление зоной», «Редактор DNS», «Записи домена» или похожим образом.

В таблице DNS-зоны обычно отображаются имя записи, тип, значение, TTL и иногда приоритет. Для корневого домена в поле имени часто используется символ @ или пустое значение. Поддомен указывается отдельно: например, запись с именем mail относится к почтовому поддомену.

При просмотре обращайте внимание на несколько деталей. Значение A-записи должно содержать корректный IP-адрес сервера. У MX-записи важен не только почтовый хост, но и приоритет: меньшее число означает более высокий приоритет. TXT-записи могут быть длинными и разбитыми на части интерфейсом панели, поэтому их нужно сверять целиком. Для CNAME нельзя одновременно использовать другие конфликтующие записи с тем же именем.

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

Командная строка позволяет получить ответ DNS-серверов напрямую и сравнить результаты из разных источников. На разных системах используются утилиты nslookup, dig и host. Они подходят для диагностики, когда нет доступа к панели управления или необходимо проверить, что запись уже видна в публичной сети.

Для запроса конкретного типа записи указывают домен и тип: A, MX, TXT, NS или другой. В ответе обычно видны найденные значения, сервер, который выполнил запрос, и дополнительные технические сведения. Запрос NS помогает определить, какие серверы считаются авторитетными для домена. После этого можно направить проверку непосредственно на один из них, чтобы увидеть актуальную версию зоны без влияния промежуточного кэша.

При анализе ответа не путайте разделы. В блоке с ответом находятся записи, которые были найдены для запроса. В дополнительном блоке могут присутствовать IP-адреса серверов, упомянутых в MX или NS. Они полезны для диагностики, но не всегда являются записями, настроенными непосредственно для проверяемого имени.

Если команда показывает старое значение, а в панели уже указано новое, проверьте TTL и время внесения изменений. Старые ответы могут сохраняться в кэше провайдера, устройства или корпоративной сети до окончания срока жизни записи.

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

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

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

Также важно отличать домен отправителя от домена в адресе почтового сервера. MX отвечает за входящую почту, а разрешение на исходящую отправку задаётся SPF, DKIM и настройками используемого почтового сервиса.

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

Вторая распространённая причина — редактирование не той DNS-зоны. Например, в панели хостинга создана запись, но домен делегирован на серверы регистратора или стороннего DNS-сервиса. Публичные запросы в таком случае будут получать данные с авторитетных NS-серверов, а не из локальной зоны хостинга.

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

Для точной диагностики последовательно проверьте NS домена, содержимое зоны на этих серверах, тип и имя нужной записи, её TTL, а затем результат запроса из публичной сети. Такой порядок помогает быстро понять, где именно находится ошибка: в делегировании, зоне, кэше или настройках самого сервиса.