DNS-записи: какие бывают и когда какая нужна

Каждый раз, когда вы открываете сайт по его имени, устройство спрашивает у DNS: «какой адрес у этого домена?». Отвечают ресурсные записи зоны — короткие строки, каждая из которых хранит один факт о домене: адрес сервера, почтовый маршрут, подтверждение владения. На практике вопрос звучит иначе: не «что такое CNAME», а «какую запись добавить, чтобы заработала почта». С этого и начнём.

A и AAAA — адреса сервера

Записи A и AAAA — это фундамент DNS. Они связывают доменное имя с IP-адресом сервера, на котором расположен сайт. Разница только в версии протокола: A указывает на адрес IPv4 (например, 93.184.216.34), а AAAA — на адрес IPv6 (например, 2606:2800:220:1:248:1893:25c8:1946). Один домен может иметь сразу несколько A- и AAAA-записей — так распределяют нагрузку между серверами.

Если у имени есть и A, и AAAA, современные устройства обычно предпочитают IPv6 и откатываются на IPv4, когда соединение не устанавливается. Отсюда практическое правило: не добавляйте AAAA, пока сервер по этому адресу действительно не отвечает — иначе часть посетителей получит задержку на каждой попытке подключения.

CNAME — псевдонимы

Запись CNAME (canonical name) делает один домен псевдонимом другого. Например, www.example.com можно сделать псевдонимом example.com, и тогда оба имени будут вести на один сайт. CNAME удобен, когда целевой адрес может меняться: вы правите его в одном месте, а все псевдонимы подхватывают изменение автоматически. Важное ограничение: CNAME нельзя ставить на корень домена (там, где уже есть записи NS и SOA), и он не может соседствовать с другими записями того же имени.

Из-за этого ограничения возникает частая задача: подключить к корню домена сервис, который выдаёт не адрес, а имя. Решается это либо A-записью на конкретный адрес, либо особым типом записи, который операторы называют ALIAS или ANAME: снаружи он выглядит как обычный ответ с адресом, а разрешение имени берёт на себя DNS-сервер. В стандарт такой тип не входит, поэтому его наличие и название стоит уточнять у своего оператора.

MX — почтовые серверы

Записи MX (mail exchanger) указывают, какие серверы принимают почту для домена. У каждой MX-записи есть приоритет — число, где меньше значит важнее. Почта сначала идёт на сервер с наименьшим приоритетом, а если он недоступен — на следующий. Так обеспечивается отказоустойчивость доставки писем.

Две вещи, на которых спотыкаются: MX должен указывать на имя, а не на адрес, и это имя обязано иметь собственную A-запись. И ещё: MX живёт на корне домена независимо от того, где находится сайт. Сайт можно переносить сколько угодно, почта от этого не пострадает — если, конечно, при переносе зоны MX-записи перенесли вместе со всем остальным.

TXT — произвольный текст, SPF, DKIM и DMARC

Запись TXT хранит произвольную текстовую информацию. Чаще всего её используют для защиты почты и подтверждения прав на домен:

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

NS и SOA — каркас зоны

Записи NS (name server) определяют, какие DNS-серверы отвечают за домен. Именно их вы указываете у регистратора, когда делегируете домен на Alviy. Запись SOA (start of authority) — служебная, она содержит параметры зоны: основной сервер, e-mail администратора, серийный номер зоны и таймеры обновления для вторичных серверов. Эти две записи создаются автоматически и формируют «каркас» любой DNS-зоны.

Серийный номер из SOA — это тот механизм, по которому вторичные серверы понимают, что зона изменилась, и забирают свежую копию. Если серийный номер не растёт, вторичные останутся со старыми данными, сколько бы вы ни правили записи на основном.

SRV, CAA и PTR — записи, которые встречаются реже

Три типа, с которыми сталкиваются не все, но когда сталкиваются — без объяснений непонятно, что происходит:

• SRV описывает, на каком хосте и порту работает конкретная служба. Имя записи строится из названия сервиса и протокола: _sip._tcp.example.com. В значении — приоритет, вес, порт и целевое имя. Так подключаются телефония, службы каталогов и часть корпоративных мессенджеров.
• CAA перечисляет удостоверяющие центры, которым разрешено выпускать сертификаты для домена. Запись не мешает работе сайта, но закрывает выпуск сертификата кем угодно ещё. Если вы добавили CAA и потом сменили провайдера сертификатов, не забудьте обновить и её — иначе выпуск не пройдёт.
• PTR отвечает на обратный вопрос: какое имя стоит за этим адресом. Живёт такая запись не в вашей зоне, а в специальной зоне владельца адреса, поэтому настраивается через хостинг-провайдера. Важна прежде всего для почтовых серверов: без корректной обратной записи письма охотно уходят в спам.

TTL — как быстро применяются изменения

У каждой записи есть TTL (time to live) — время в секундах, на которое ответ кэшируется на промежуточных DNS-серверах. Пока TTL не истёк, изменения записи не видны части пользователей. Поэтому перед переносом сайта TTL заранее понижают (например, до 300 секунд), чтобы переключение прошло почти мгновенно, а после — возвращают обратно, чтобы снизить нагрузку.

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

Типовые наборы записей

На практике записи почти всегда идут комплектами. Три набора закрывают большинство случаев.

Только сайт. A-запись на корень домена, CNAME для www на корень. Всё. Если сайт работает через проксирование, вместо адреса сервера в A-записи окажется адрес фильтрующей сети, а реальный адрес наружу не попадёт.

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

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

Ошибки, которые встречаются чаще всего

• CNAME на корне домена. Запрещён стандартом, и редактор зоны его не пропустит. Нужен либо адрес в A-записи, либо ALIAS-подобный тип у оператора.
• Две SPF-записи. Появляются, когда подключают второй почтовый сервис и просто добавляют ещё одну строку. Правильно — объединить всё в одну запись.
• MX на IP-адрес. Значение MX обязано быть именем, у которого есть своя A-запись.
• Потерянные при переезде TXT и MX. Переносить зону надо целиком, а не только то, что видно на сайте.
• Высокий TTL перед работами. Понижать нужно заранее, иначе переключение растянется на сутки.
• Записи для сервисов, которыми давно не пользуются. Старая A-запись на выключённый сервер или заброшенный поддомен — это и лишний мусор, и подсказка для того, кто изучает вашу инфраструктуру.

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