Типы ресурсных записей DNS

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

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

Имя записи может относиться к корню домена или к отдельному хосту. Например, для домена можно создать запись для поддомена www, почтового имени или служебного имени для верификации. В одной зоне допускается несколько записей одного типа, если это соответствует задаче.

Запись A связывает доменное имя с IPv4-адресом. Она используется для открытия сайтов, подключения к сервисам и направления трафика на сервер. Если у проекта несколько серверов, для одного имени можно указать несколько A-записей. В этом случае ответы могут возвращаться поочередно, что дает простое распределение нагрузки, но не заменяет полноценную балансировку.

Запись AAAA выполняет ту же функцию для IPv6-адреса. Современные проекты часто используют A и AAAA одновременно: клиенты с поддержкой IPv6 подключаются по новому протоколу, а остальные продолжают работать через IPv4.

CNAME создает псевдоним: одно имя указывает на другое каноническое имя. Это удобно, когда поддомен должен следовать за адресом внешней платформы или основной записью проекта. Резолвер сначала получает целевое имя, а затем ищет его A или AAAA-запись. Для одного имени CNAME нельзя одновременно создавать другие обычные записи, поскольку псевдоним должен быть единственным источником данных. На корне домена CNAME обычно не применяется из-за обязательных записей зоны.

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

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

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

Запись MX задает почтовый сервер, принимающий письма для домена. В ее данных указывают приоритет и имя почтового хоста. Чем меньше число приоритета, тем предпочтительнее сервер. Допускается несколько MX-записей для резервирования, однако каждая из них должна вести на имя, у которого есть A или AAAA-запись, а не на CNAME.

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

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

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

CAA ограничивает перечень центров сертификации, которым разрешено выпускать сертификаты для домена. Можно разрешить выпуск обычных сертификатов, сертификатов с расширенной проверкой либо запретить выпуск определенному центру. CAA снижает риск ошибочной выдачи сертификата, но требует аккуратности: неверная политика способна заблокировать выпуск или продление сертификата.

Для DNSSEC применяются записи DNSKEY, DS, RRSIG и другие служебные типы. Они формируют цепочку доверия и позволяют резолверу проверить, что DNS-ответ не был подменен. Настройка DNSSEC требует согласованности между зоной и регистратором: ошибка в ключах или DS-записи может сделать домен недоступным для проверяющих резолверов.

Для публикации сайта на конкретном сервере выбирают A и при необходимости AAAA. Если поддомен должен быть алиасом другого имени, используют CNAME. Для приема почты нужны MX-записи, а для защиты и подтверждения почтовой конфигурации — TXT-записи с SPF, DKIM и DMARC. Делегирование поддомена выполняют через NS, а обратное соответствие адреса и имени — через PTR.

• Проверяйте, что имя и значение записи введены в нужной зоне.
• Не создавайте CNAME рядом с A, MX, TXT или другими записями для того же имени.
• Указывайте для MX и SRV имена хостов, а не IP-адреса.
• Перед крупными изменениями уменьшайте TTL и сохраняйте прежние значения.
• Учитывайте задержку распространения данных из-за кэширования.
• После редактирования проверяйте ответы DNS из разных сетей и работу целевого сервиса.

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