Что такое DNS-записи? A, AAAA, CNAME, MX, TXT и NS с примерами

Это руководство разбирает шесть типов DNS-записей, с которыми вы реально столкнётесь, поддерживая сайт или почту на своём домене: A, AAAA, CNAME, MX, TXT и NS. Для каждого типа даны краткое определение, реалистичный пример и классическая ошибка, которую мы регулярно видим в тикетах поддержки. Текст написан для разработчиков и администраторов, которые сами редактируют свои зоны, а в конце разобраны стратегия TTL, то, как на самом деле работает распространение изменений, и команды dig для проверки всего перечисленного.

Шесть типов записей по порядку

A: имя в адрес IPv4

Запись A сопоставляет имя хоста с адресом IPv4. Именно она заставляет ваш домен открываться в браузере.

example.com.      3600  IN  A      203.0.113.10

Классическая ошибка: опубликовать внутренний адрес сервера. Запись A, указывающая на 192.168.1.20, корректно резолвится, а затем даёт таймаут всем за пределами вашей сети. Всегда публикуйте публичный IP.

AAAA: имя в адрес IPv6

Запись AAAA делает то же самое для IPv6.

example.com.      3600  IN  AAAA   2001:db8:10::1

Классическая ошибка: добавить запись AAAA для сервера, на котором IPv6 на самом деле не настроен. Клиенты, предпочитающие IPv6, попробуют его первым, зависнут, и лишь часть корректно переключится обратно, поэтому страницы грузятся медленно или не грузятся вовсе, и воспроизвести это сложно. Публикуйте AAAA только после того, как сами проверили адрес.

CNAME: псевдоним для другого имени

CNAME делает одно имя псевдонимом другого, и дальше поиск продолжается по цели.

www.example.com.  3600  IN  CNAME  example.com.

Классическая ошибка: CNAME на вершине зоны (apex), то есть на самом example.com. Стандарт это запрещает: CNAME не может сосуществовать с другими записями для того же имени, а на вершине обязаны находиться записи SOA и NS. Используйте на вершине запись A или AAAA либо тип ALIAS или ANAME, если ваш DNS-провайдер его поддерживает.

MX: куда доставляется почта

Записи MX называют серверы, принимающие почту домена, с числовым приоритетом, где меньшее значение важнее.

example.com.      3600  IN  MX     10 mail.example.com.
mail.example.com. 3600  IN  A      203.0.113.25

Классическая ошибка: MX, указывающий на IP-адрес. В правой части MX должно стоять имя хоста с собственной записью A или AAAA; MX 10 203.0.113.25 некорректен, и строгие почтовые серверы откажутся доставлять письма. Цель также не должна быть CNAME.

TXT: произвольный текст, в основном почтовая политика

Записи TXT хранят произвольный текст. На практике они несут почтовую политику (SPF, DKIM, DMARC) и подтверждения владения доменом.

example.com.      3600  IN  TXT    "v=spf1 mx a -all"

Классическая ошибка: кавычки. Большинство панелей управления добавляют кавычки сами, поэтому вставка значения, где они уже есть, публикует буквальные символы кавычек, и проверка SPF падает. Вторая ловушка: длина. Одна строка в кавычках вмещает не более 255 символов, поэтому длинный ключ DKIM нужно разбивать на несколько строк в кавычках. Проверяйте опубликованное значение через dig, а не доверяйте форме.

NS: кто авторитетен для зоны

Записи NS объявляют, какие серверы имён авторитетны для зоны.

example.com.      86400 IN  NS     ns1.cloudhosting.lv.
example.com.      86400 IN  NS     ns2.cloudhosting.lv.

Классическая ошибка: отредактировать записи NS внутри зоны и ждать, что мир последует за ними. Делегирование, которым реально пользуются резолверы, живёт в реестре и меняется через регистратора. Если они расходятся, побеждает реестр, а ваши правки в зоне остаются невидимыми.

TTL: время жизни кэша и приём перед миграцией

TTL задаёт число секунд, в течение которых резолвер имеет право кэшировать ответ. Для большинства записей разумное значение по умолчанию 3600, а 86400 подходит записям, которые никогда не меняются. Низкий TTL означает быстрые изменения, но больше запросов к серверам имён.

Перед любым запланированным переездом используйте стандартный приём:

1. Снизьте TTL изменяемой записи до 300 минимум за один полный старый TTL до миграции. За сутки будет надёжно.
2. Выждите старый TTL, чтобы каждый кэш успел забрать короткое значение.
3. Измените запись. Худшее окно устаревших данных теперь 5 минут, а не час и не сутки.
4. Когда новый сервер подтверждённо работает, верните TTL к обычному значению.

Как на самом деле работает распространение

Глобальной рассылки не существует. Когда вы меняете запись, никуда ничего не отправляется: авторитетные серверы просто начинают отдавать новый ответ тем, кто спрашивает. Каждый резолвер, закэшировавший старый ответ, продолжает возвращать его, пока не истечёт срок его собственной копии, а поскольку каждый резолвер забирал запись в свой момент, копии и истекают в разные моменты. В этом всё объяснение фразы "у меня сайт работает, а у вас нет" во время миграции.

Отсюда два вывода. Заставить удалённые кэши забыть запись раньше срока нельзя, именно поэтому важен приём с TTL выше. А смена NS самая медленная из всех, потому что серверы TLD отдают делегирование со своим собственным TTL, обычно от 24 до 48 часов, независимо от того, что вы задали в зоне.

Проверка каждой записи через dig

dig входит в любой дистрибутив Linux и в macOS. Флаг +short печатает только ответ.

dig A     example.com +short
dig AAAA  example.com +short
dig CNAME www.example.com +short
dig MX    example.com +short
dig TXT   example.com +short
dig NS    example.com +short

Три варианта, которые стоит запомнить:

# спросить авторитетный сервер напрямую, минуя все кэши
dig A example.com @ns1.cloudhosting.lv +short

# запустить дважды к своему резолверу и смотреть, как убывает TTL
dig A example.com

# пройти всю цепочку делегирования от корневых серверов
dig A example.com +trace

Запрос к авторитетному серверу самый важный. Если он уже возвращает новое значение, ваше изменение опубликовано, а всё остальное лишь постепенное опустошение кэшей. Обычный запрос показывает оставшийся TTL во втором столбце, и по нему видно, когда именно ваш резолвер перезапросит запись.

Где вы будете всё это редактировать на практике

Любому домену нужна рабочая зона раньше всего остального, поэтому обычный порядок такой: получить домен, направить записи NS на своего DNS-провайдера, затем создать записи A, MX и TXT для своих сервисов. Если вы регистрируете домен у нас, управление DNS уже включено, и делегирование NS с самого начала настроено правильно. На наших тарифах хостинга сайтов записи A, MX и SPF создаются за вас, что убирает большинство описанных выше ошибок. В любом случае держите dig под рукой: он за секунду отвечает на то, на что тикет в поддержку отвечает за час.