DNS-записи для сайта: A, AAAA, CNAME, MX и TXT без путаницы

Одна зона, но разные роли записей

DNS-зона сайта похожа на аккуратный шкаф с разными полками. A и AAAA ведут веб-трафик к IP-адресам, CNAME связывает имя с другим именем, MX отвечает за почту, TXT хранит подтверждения и политики, а NS показывает, кто управляет зоной. Ошибка начинается там, где все записи воспринимают как одинаковые строки в панели.

Для сайта важнее не просто «заполнить DNS», а понимать, какая запись за что отвечает. Удалили TXT — может сломаться подтверждение домена или почтовая авторизация. Изменили CNAME — перестал работать help-раздел. Заменили A, но забыли AAAA — часть пользователей через IPv6 продолжила попадать на старый сервер. Поэтому первичная настройка после покупки домена должна быть связана с картой зоны, а не с набором случайных правок. Базу удобно сверить с материалом про DNS после покупки домена.

A и AAAA ведут к серверу, но не всегда вместе

A-запись указывает IPv4-адрес, AAAA — IPv6-адрес. Если сайт переезжает на новый сервер, но меняется только A, пользователи с IPv6 могут видеть другую картину. Иногда это выглядит как «у меня сайт уже новый, у клиента старый». На самом деле два типа адресов ведут в разные места.

Для VPN-сайта, кабинета или панели поддержки это особенно неприятно: пользователь открывает страницу, но попадает не туда, где лежит актуальная версия. При диагностике полезно отдельно смотреть A и AAAA, а затем сверять, что сервер, сертификат и приложение готовы принимать оба маршрута. Если IPv6 не используется, лучше не оставлять старую AAAA-запись «на всякий случай».

CNAME удобен, пока не прячет ответственность

CNAME часто используют для `www`, help-раздела, документации, внешних платформ и статуса. Он удобен, потому что имя наследует адрес другого имени. Но CNAME также может скрыть цепочку зависимости: пользователь видит ваш поддомен, а ответ фактически приходит от внешнего сервиса.

В корне домена CNAME обычно не используют как обычную запись из-за ограничений DNS и соседства с другими типами записей. Для поддоменов он нормален, если команда понимает, куда он ведёт, кто управляет целевым именем и что будет при сбое внешней платформы. Если поддомены начинают выполнять разные роли — API, кабинет, инструкции, статус — полезно заранее определить, когда поддомены действительно нужны, а когда достаточно папки на основном сайте.

MX и TXT нельзя трогать как «служебный мусор»

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

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

Практический разбор зоны

Минимальная проверка перед правкой:

1. выписать все A и AAAA для сайта, кабинета, API и help-раздела;

2. проверить CNAME-цепочки и понять, где внешний сервис;

3. отдельно сохранить MX и TXT;

4. уточнить TTL у записей, которые будут меняться;

5. после правки сравнить ответ авторитетного сервера и публичных резолверов.

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

Кейс: сайт переехал, а почта пропала

Команда перенесла сайт на новый хостинг и вручную создала A-запись в новой зоне. Веб-страница открылась, поэтому миграцию посчитали законченной. Через несколько часов выяснилось, что письма на support@ не приходят. В старой зоне были MX и SPF, а в новой их не перенесли.

Проблему нашли через проверку MX и заголовков тестового письма. После восстановления MX, SPF и DKIM почта снова заработала. Главный урок: DNS-записи сайта — это не только веб. Если в зоне есть почта, подтверждения и внешние сервисы, перенос одной A-записи не равен переносу проекта.

Контроль зоны после правок

для каждой записи понятно, какую задачу она решает;
A и AAAA ведут в ожидаемое место;
CNAME не скрывает неизвестную зависимость;
MX и TXT сохранены перед переносом;
после изменения проверен авторитетный ответ;
связанные правки выполняются по плану, а не из памяти.

Как связать типы записей с реальными компонентами сервиса

Веб-адрес и узел подключения

Сайт VPN сервиса может иметь собственные A и AAAA. Домен для VPN сервера может указывать на другой узел. Адрес VPN сервера должен быть доступен по опубликованному семейству адресов. Домен VPN не следует настраивать копированием одного IP во все поля: у записей разные роли и ограничения.

Подписки, почта и подтверждения

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

Настройки устройства — другой уровень

DNS сервер для VPN и DNS для VPN клиента относятся к разрешению имён на стороне подключения. DNS через VPN описывает маршрут запросов. DNS и VPN проверяют по разным этапам. Настроить DNS для VPN корректно можно после определения, меняется ли авторитетная зона, резолвер клиента или оба компонента по отдельности.

Проверка после правки

DNS для ВПН сверяйте с текущим оператором зоны и кешем. VPN соединение проверяйте новой попыткой. Проверить VPN соединение полезно тем же безопасным запросом до и после изменения. Хостинг для VPN должен обслуживать опубликованный адрес: правильная запись не запускает остановленный процесс и не открывает нужный порт.

FAQ о DNS-записях

Можно ли удалить TXT, если сайт открывается нормально?

Нет. TXT может отвечать за почту, доменное подтверждение, SPF, DKIM, DMARC или внешний сервис.

Почему AAAA ломает сайт, если A-запись правильная?

Пользователь с IPv6 может пойти по AAAA и попасть на другой сервер. Поэтому A и AAAA проверяют отдельно.

CNAME всегда лучше A-записи?

Нет. CNAME удобен для поддоменов и внешних сервисов, но он добавляет зависимость от целевого имени.

Что проверять после изменения DNS-записи?

Тип записи, авторитетный ответ, публичные резолверы, TTL и связанный сервис: сайт, почту, API или подтверждение.

Какая запись нужна, если корпоративный VPN сервер доступен по имени?

Для прямого указания IPv4 используют A, для IPv6 — AAAA; псевдоним через CNAME применяют с учётом ограничений DNS и выбранного имени. Публикуйте только реально работающие адреса. Наличие AAAA без доступного IPv6 может давать разные результаты на разных устройствах.

Какие записи нужны, если корпоративный VPN сервер доступен по имени?

Нужные типы записей зависят от адресов и архитектуры сервиса. Сначала проверьте DNS для VPN для конкретного имени, затем определите, какие поддомены VPN относятся к кабинету, подписке и узлам. MX и TXT почты не заменяют A или AAAA сервера; переносите только относящиеся к задаче записи.

Источники

---