DNS-записи: как настроить A, AAAA, CNAME, MX и TXT без ошибок

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

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

В этом руководстве разберем основные типы записей, типовые конфигурации и порядок изменений без лишнего простоя.

Что такое DNS простыми словами

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

Упрощенный маршрут:

1. браузер или операционная система проверяет локальный кеш;
2. рекурсивный резолвер ищет ответ;
3. корневые и TLD-серверы указывают авторитетные nameserver;
4. авторитетный сервер возвращает запись из DNS-зоны;
5. ответ кешируется на время TTL.

Проверить записи, видимые в интернете сейчас, можно через DNS Lookup BB STUDIO. Но перед изменением все равно определите, какой провайдер обслуживает авторитетную зону.

Домен, nameserver и DNS-зона — разные сущности

Регистратор хранит регистрацию домена и управляет делегированием. Nameserver отвечает за DNS-зону. DNS-зона содержит A, MX, TXT и другие resource records.

Например, домен можно зарегистрировать у одной компании, использовать DNS Cloudflare, разместить сайт на другом хостинге, а почту — в Google Workspace или Microsoft 365. Это нормальная архитектура.

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

Перед работой зафиксируйте:

• текущие авторитетные NS;
• провайдера активной DNS-зоны;
• полный экспорт или скриншот зоны;
• старый и новый IP сервера;
• все сервисы, зависящие от домена;
• доступ к регистратору, DNS и хостингу.

Основные типы DNS-записей

A — имя на IPv4-адрес

A-запись связывает hostname с IPv4-адресом.

Type: A
Name: @
Value: 192.0.2.10
TTL: 300

Символ @ во многих панелях обозначает корень зоны: example.com. Для поддомена в Name указывают, например, shop или api.

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

AAAA — имя на IPv6-адрес

AAAA выполняет аналогичную функцию для IPv6.

Type: AAAA
Name: @
Value: 2001:db8::10
TTL: 300

Не добавляйте AAAA «для полноты», если сервер не обслуживает сайт через IPv6. Часть устройств может предпочесть IPv6 и получить ошибку, хотя IPv4 работает.

CNAME — псевдоним другого имени

CNAME указывает на другой hostname, а не на IP.

Type: CNAME
Name: www
Target: example.com
TTL: 300

Его часто используют для www, CDN, SaaS-платформ и технических поддоменов. На одном и том же имени CNAME не должен конфликтовать с другими типами записей.

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

MX — маршрутизация корпоративной почты

MX-записи определяют серверы, принимающие почту для домена. Каждое значение содержит hostname почтового сервера и приоритет.

Type: MX
Name: @
Priority: 10
Target: mail.example.net
TTL: 3600

Меньшее число означает более высокий приоритет. Если почтовый провайдер предоставляет несколько MX, добавьте все в точности по инструкции. MX должен указывать на hostname, а не прямо на IP, и не должен вести на имя, которое существует только как CNAME.

Перенос сайта не требует автоматической замены MX. Если почта находится в отдельном сервисе, сохраните ее записи.

TXT — политики и подтверждение домена

TXT часто используют для:

• подтверждения владения доменом;
• SPF-политики отправителей;
• открытого ключа DKIM;
• политики и отчетов DMARC;
• verification-токенов поисковых, рекламных и SaaS-сервисов.

Домен может иметь несколько TXT, особенно на разных именах. Но две отдельные SPF-политики на корне вызывают ошибку проверки SPF. Все разрешенные источники нужно объединить в одну корректную политику.

Используйте генератор SPF и генератор DMARC для подготовки синтаксиса, затем сравните значения с актуальной документацией почтового провайдера.

NS — делегирование

NS определяют авторитетные nameserver. На уровне регистратора они делегируют весь домен, а внутри зоны могут делегировать отдельный поддомен.

Не меняйте NS как обычный способ «подключить хостинг». Замена NS переносит ответственность за всю зону. Если в новой зоне отсутствуют MX, TXT, CAA или служебные поддомены, соответствующие сервисы перестанут работать.

CAA — разрешенные центры сертификации

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

Проверьте, какой центр сертификации использует хостинг или CDN.

SRV — hostname и порт сервиса

SRV описывает целевой hostname, порт, приоритет и вес сетевого сервиса. Его используют VoIP, корпоративные чаты и другие протоколы. Переносите значения строго по документации, включая подчеркивания в имени службы и протокола.

Поля Name, Value, Priority и TTL

DNS не направляет на путь страницы. Адрес https://example.com/catalog/ не является корректной целью A или CNAME. Переадресацию на конкретный URL выполняет вебсервер или приложение.

Как работает TTL и распространение DNS

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

Практический порядок миграции:

1. за 24–48 часов уменьшить TTL затрагиваемых записей, например до 300 секунд;
2. дождаться завершения старого высокого TTL;
3. подготовить и проверить новый сервер до публичного переключения;
4. изменить только необходимые записи;
5. оставить старый сервер доступным на переходный период;
6. после проверки вернуть нормальный рабочий TTL.

Распространение — не единый процесс с глобальной кнопкой завершения. Авторитетные серверы могут сразу возвращать новое значение, пока рекурсивные резолверы продолжают использовать кеш.

Типовые конфигурации

Сайт на одном сервере

@      A       192.0.2.10
www    CNAME   example.com

Вебсервер должен принимать оба hostname, а сертификат — покрывать example.com и www.example.com.

Сайт и почта у разных провайдеров

@      A       192.0.2.10
www    CNAME   example.com
@      MX 10   mail.provider.example
@      TXT     v=spf1 include:provider.example -all

Изменение A влияет на сайт, но не должно удалять MX или TXT. Поэтому полная очистка зоны во время переноса хостинга опасна.

Поддомен для внешней платформы

shop   CNAME   shops.platform.example

На платформе также нужно добавить shop.example.com, подтвердить его и дождаться SSL. Одной DNS-записи недостаточно для настройки приложения.

Как подключить домен к хостингу

Надежная последовательность:

1. добавьте домен в панель нового хостинга;
2. загрузите сайт и базу данных;
3. настройте переменные окружения, cron, отправку писем и кеш;
4. проверьте сайт через временный адрес или локальный hosts-файл;
5. получите точные A, AAAA или CNAME от хостинга;
6. измените только нужные DNS-записи;
7. выпустите или проверьте SSL;
8. протестируйте страницы, формы, платежи и почту;
9. оставьте старый сервер доступным во время перехода.

Если инфраструктура еще не выбрана, сравните требования и форматы хостинга для сайта. Во время разработки сайта зафиксируйте все рабочие домены, поддомены и внешние интеграции до запуска.

Перенос DNS без простоя

Замена nameserver требует больше подготовки, чем изменение одной A-записи.

До изменения NS

• создайте новую зону со всеми текущими записями;
• сравните A, AAAA, CNAME, MX, TXT, CAA и SRV;
• включите служебные поддомены;
• скопируйте SPF, DKIM и DMARC;
• заранее уменьшите TTL в старой зоне;
• убедитесь, что DNSSEC не оставит устаревшую DS-запись.

Во время изменения

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

После изменения

• убедитесь, что авторитетные серверы отвечают одинаково;
• отправьте и примите тестовые письма;
• проверьте формы, платежи, webhooks и API;
• отключайте старую инфраструктуру только после стабильного перехода.

DNS и корпоративная почта

MX управляет приемом писем. SPF, DKIM и DMARC обычно обеспечивают аутентификацию отправителей и защиту от подмены.

• SPF перечисляет разрешенную инфраструктуру отправки;
• DKIM добавляет криптографическую подпись, открытый ключ которой публикуется в DNS;
• DMARC задает политику и отчетность на основе согласованной аутентификации.

Не придумывайте значения. Копируйте MX, DKIM selector и SPF include из панели поставщика. Начинайте DMARC с мониторинга, изучайте отчеты и только затем усиливайте политику, чтобы не заблокировать легальные рассылки и транзакционные письма.

DNS, HTTPS и индексация

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

Проверьте:

• HTTP и HTTPS;
• корень домена и www;
• все языковые версии;
• canonical и sitemap;
• robots.txt;
• ответы 200, 301, 404 и 5xx;
• Search Console после переноса.

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

В браузерном инструменте

Проверьте A, AAAA, CNAME, MX, TXT, NS и CAA. Смотрите не только наличие нужного значения, но также авторитетные NS и TTL.

Через командную строку

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

С dig:

dig example.com A
dig www.example.com CNAME
dig example.com MX
dig example.com TXT
dig example.com NS

Для глубокой диагностики запросите конкретный авторитетный nameserver и сравните его ответ с публичными рекурсивными резолверами. Команда ipconfig /flushdns очищает локальный кеш Windows, но не кеш провайдера и не весь интернет.

Типичные ошибки DNS

1. Записи редактируют вне авторитетной зоны.
2. Панель дважды дописывает домен в Name.
3. Полный URL с https:// вставляют в CNAME или MX.
4. CNAME конфликтует с другой записью на том же имени.
5. AAAA ведет на сервер без рабочего IPv6.
6. Во время переноса пропадают MX, SPF, DKIM или DMARC.
7. Публикуются две отдельные SPF-политики.
8. MX ведет на IP или CNAME-псевдоним.
9. Nameserver меняют без полной копии зоны.
10. TTL уменьшают только после переключения.
11. Старый сервер отключают сразу.
12. DNSSEC остается связан со старым провайдером.
13. Wildcard используют вместо точных поддоменов без причины.
14. После DNS не тестируют SSL, формы и почту.

Безопасность DNS

• включите двухфакторную аутентификацию у регистратора и DNS-провайдера;
• используйте отдельные учетные записи и минимальные права;
• включите блокировку переноса домена;
• храните резервные копии зоны;
• ведите журнал изменений;
• удаляйте устаревшие verification TXT;
• находите dangling CNAME, ведущие на удаленные сторонние ресурсы;
• настраивайте DNSSEC только с контролируемым процессом DNSKEY и DS;
• следите за сроком регистрации и контактами владельца.

Dangling CNAME особенно опасен. Если поддомен ведет на удаленный ресурс SaaS, другая сторона иногда может зарегистрировать такой ресурс и получить контроль над поддоменом.

Чек-лист перед изменением

• авторитетный DNS-провайдер определен;
• текущая зона сохранена;
• тип записи соответствует документации сервиса;
• Name не дублирует домен;
• Value не содержит лишний протокол или путь;
• IP или hostname проверен;
• TTL соответствует плану миграции;
• MX и почтовые TXT остаются на месте;
• CNAME не конфликтует с другими записями;
• AAAA используется только с рабочим IPv6;
• SSL сможет покрыть новый hostname;
• способ проверки и отката задокументирован;
• старый сервер останется доступным на время перехода.

Вывод

Безопасная настройка DNS начинается с карты зависимостей домена, а не с кнопки Add record. A и AAAA ведут на адреса, CNAME создает псевдоним, MX управляет приемом почты, TXT хранит политики и подтверждения, а NS определяет расположение авторитетной зоны.

Меняйте только необходимые записи, заранее уменьшайте TTL, сохраняйте почтовые настройки и проверяйте сайт, HTTPS и почту отдельно. Для безопасного переноса, аудита зоны или восстановления недоступного сайта закажите техническую поддержку BB STUDIO или свяжитесь с командой.