DNS-записи сайта простыми словами: A, CNAME, MX и TXT
Четыре типа DNS-записей отвечают за адрес сайта, его псевдонимы, почту и подтверждения владения доменом. Разбираем, что делает каждая, где её чаще всего ломают и как проверить.
DNS-записи сайта — это строки в настройках домена, которые говорят интернету, где находится сайт, куда доставлять почту и кто может подтверждать владение доменом. Запись A указывает на IP-адрес сервера, CNAME — на другое доменное имя, MX — на почтовый сервер, TXT хранит произвольный текст: проверочные коды и правила защиты почты.
Обычно записи ставят один раз и забывают. Проблемы начинаются при смене хостинга, подключении почты, CDN или сервиса рассылок: одна неверная строка, и сайт открывается у одних и не открывается у других, а письма клиентов не доходят. Пока вы ничего не меняете, DNS трогать не нужно. Если же сайт переезжает или подключается новый сервис, записи стоит проверить до и после.
Что такое DNS-запись и зачем их несколько
Браузер ходит по IP-адресам, а люди запоминают названия. DNS связывает одно с другим, система описана в RFC 1034 и RFC 1035. У одного домена бывает много записей разных типов, и каждая отвечает за свою задачу.
| Тип | Что хранит | За что отвечает |
|---|---|---|
| A | IPv4-адрес | Адрес сервера, на котором лежит сайт |
| AAAA | IPv6-адрес | То же самое для IPv6 |
| CNAME | Другое доменное имя | Псевдоним: этот адрес — то же самое, что вон тот |
| MX | Имя почтового сервера и приоритет | Куда доставлять письма на адреса вашего домена |
| TXT | Текст | Подтверждения владения, SPF, DKIM, DMARC |
У каждой записи есть TTL — время в секундах, в течение которого чужие серверы могут держать ответ в кеше. Поэтому изменение вступает в силу не мгновенно: пока кеш не истёк, часть пользователей видит старые данные. Перед переездом TTL заранее уменьшают, а когда всё стабилизировалось, возвращают.
Куда ведут записи A и CNAME
Запись A связывает имя с IP-адресом. Для example.ru это выглядит так: example.ru → 203.0.113.10. Сменился хостинг и IP новый — правят именно её. Если у сервера есть IPv6, добавляют ещё и AAAA, и следить нужно за обеими: забытая AAAA со старым адресом уводит часть посетителей на прежний сервер.
CNAME — псевдоним. Запись www.example.ru → example.ru означает: ищи адрес там, где он у example.ru. Это удобно, когда сервис сам меняет IP (CDN, конструктор сайтов, платформа): вы указываете на их имя, и их адреса вас не касаются.
Главное ограничение CNAME описано в RFC 1034, раздел 3.6.2: если у имени есть CNAME, других данных у него быть не должно. Для корня домена (example.ru без www) это значит, что CNAME нельзя поставить рядом с MX и TXT. Некоторые регистраторы и DNS-хостинги обходят запрет своими записями вроде ALIAS или ANAME, но это их надстройка, а не стандарт, так что ищите детали в справке провайдера.
Что выбрать:
- Корень домена, свой сервер с постоянным IP — запись A.
- Поддомен, который ведёт на сервис (магазин, блог, страница статуса) — CNAME на имя, которое дал сервис.
- Нужны и сайт, и почта на корне домена — A для сайта, MX и TXT рядом, а CNAME на корне не ставим.
Для страницы статуса на домене клиента как раз используют CNAME на поддомене, подробнее об этом в статье про страницу статуса на домене клиента.
Куда приходит почта: запись MX
MX говорит отправляющему серверу, куда доставлять письма для адресов вида info@example.ru. У записи два поля: приоритет и имя почтового сервера. Порядок описан в RFC 5321, раздел 5.1: сначала пробуют сервер с меньшим числом приоритета, а если он недоступен, следующий.
Пример для почты у стороннего провайдера:
example.ru. MX 10 mx1.mail-provider.example.
example.ru. MX 20 mx2.mail-provider.example.
Три практических момента:
- MX указывает на имя, а не на IP, и у этого имени должна быть своя запись A или AAAA. Направлять MX на псевдоним (CNAME) нельзя, это прямо запрещает RFC 2181, раздел 10.3.
- Сайт и почта независимы. Домен можно перенести на новый хостинг, не трогая MX; сайт на одном сервере, а почта у другого провайдера — обычная схема.
- Если MX нет совсем, отправитель по правилам того же RFC 5321 пробует доставить письмо на адрес из A-записи самого домена. Почтового сервера там, как правило, нет, и письма теряются. Бизнес узнаёт об этом по пропавшим заявкам, а не из уведомлений.
С исходящей почтой другая история. Если письма с вашего сайта попадают в спам, причина часто в TXT-записях, о них дальше. Отдельный разбор — в статье про письма с сайта, которые попадают в спам.
Для чего нужна запись TXT
TXT — запись свободного текста, поэтому её используют для всего подряд. Типичные применения:
- Подтверждение владения доменом. Вебмастера поисковых систем, почтовые и рекламные сервисы просят добавить TXT с проверочным кодом. Так они убеждаются, что вы управляете DNS, а значит, и доменом.
- Выпуск сертификатов. При проверке DNS-01 Let's Encrypt просит подтвердить контроль над доменом, разместив определённое значение в TXT-записи.
- SPF — список серверов, которым разрешено отправлять почту от имени домена. Формат описан в RFC 7208.
- DKIM — цифровая подпись писем, публичный ключ лежит в TXT. Стандарт: RFC 6376.
- DMARC — правило, что делать с письмами, не прошедшими SPF и DKIM. Описан в RFC 7489.
SPF-запись у домена должна быть одна: RFC 7208, раздел 3.2 запрещает несколько таких записей, а при их наличии проверка завершается ошибкой (permerror). Частая ситуация: подключили сервис рассылок, он попросил добавить свою SPF-строку, и её добавили второй записью вместо того, чтобы объединить с первой.
Ошибки, из-за которых падает сайт или почта
Чаще всего ломается не сам DNS, а правка, сделанная без проверки последствий. Типичные сочетания «признак → причина → что делать»:
| Что видите | Вероятная причина | Что делать |
|---|---|---|
| Сайт открывается у вас, но не у клиента | Разные IP в A и AAAA или старый кеш | Сверить A и AAAA, дождаться окончания TTL, проверить из других мест |
| Письма на домен не приходят | Пропала или изменена MX-запись | Вернуть MX у провайдера почты, проверить приоритеты |
| Почта уходит в спам | Нет SPF или DKIM, либо две SPF-записи | Объединить SPF в одну запись, добавить DKIM |
| Поддомен перестал работать | CNAME ведёт на имя, которого уже нет | Уточнить актуальное имя у сервиса и обновить запись |
| Сертификат не выпускается | Нет нужной TXT или она ещё не обновилась | Проверить TXT и подождать истечения TTL |
| Пропало всё сразу | Домен не продлён или сменились DNS-серверы | Проверить срок регистрации и NS-записи |
Последняя строка заслуживает внимания: когда домен не продлили, перестают работать и сайт, и почта одновременно. Как не потерять домен — в статье про срок регистрации домена. А если сайт просто не открывается и непонятно, у кого проблема, начните с разбора «Сайт не открывается».
Отдельный риск — переезд. При смене хостинга меняют A-запись, а про MX и TXT забывают, или переносят зону целиком и затирают то, что настроено у почтового провайдера. Перед любой правкой сохраните текущий список записей, чтобы было куда откатиться.
Как проверить DNS-записи прямо сейчас
Для разовой проверки хватит терминала. Команды работают на macOS и Linux, в Windows есть nslookup:
- Адрес сайта:
dig example.ru A(иdig example.ru AAAA, если используете IPv6). - Псевдоним:
dig www.example.ru CNAME. - Почта:
dig example.ru MX. Проверьте, что серверы и приоритеты совпадают с теми, что дал провайдер. - Текстовые записи:
dig example.ru TXT. Найдите SPF и проверочные коды; для DMARC запрашивайте_dmarc.example.ru. - Сравните ответы разных DNS-серверов:
dig @8.8.8.8 example.ru Aи ответ вашего DNS-хостинга. Если они расходятся, изменения ещё не разошлись или записи внесены не там.
Если после правки вы видите старое значение, это почти всегда кеш. Дождитесь окончания TTL, а не меняйте запись по второму кругу.
Быстро посмотреть записи домена без терминала можно на странице проверки DNS-записей Обходчика: вводите домен и видите A, MX, TXT и другие записи одним списком. Заодно убедитесь, что срок регистрации не заканчивается на днях, — для этого есть мониторинг срока регистрации домена. Обе проверки бесплатные и работают без регистрации.