DNS-записи: A, AAAA, CNAME, MX, TXT и SRV простыми словами

DNS-записи — это настройки домена, которые отвечают на вопросы вроде: «на какой IP-адрес отправить пользователя», «какой сервер принимает почту», «как подтвердить владение доменом» или «где находится нужный сервис». Когда сайт не открывается, почта не доходит или новый сервис не видит домен, причина часто оказывается именно в DNS.

DNS удобно представлять как распределённую адресную книгу интернета. Домен example.com сам по себе не говорит браузеру, куда подключаться. Браузеру нужен IP-адрес, почтовому серверу — маршрут для доставки писем, а некоторым приложениям — адрес и порт конкретного сервиса. Всё это описывается DNS-записями.

Разберём основные типы DNS-записей: A, AAAA, CNAME, MX, TXT и SRV. Этого набора хватает для большинства сайтов, API, почтовых доменов, SaaS-интеграций и базовой диагностики доступности.

Что такое DNS-записи и где они хранятся

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

Например, для домена example.com в зоне могут быть записи:

example.com.        3600  IN  A      203.0.113.10
www.example.com.    3600  IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mail.example.com.
example.com.        3600  IN  TXT    "v=spf1 include:_spf.example.net ~all"

Если упростить, каждая запись говорит: «для такого имени и такого типа запроса верни такое значение».

Когда пользователь открывает сайт, происходит цепочка DNS-запросов: браузер или операционная система спрашивает резолвер, резолвер обращается к DNS-серверам и получает нужную запись. Подробно этот путь разобран в статье «Как работает DNS. От запроса до IP-адреса, простыми словами».

У одной доменной зоны может быть много записей. Например:

• example.com — основной сайт;
• www.example.com — версия с www;
• api.example.com — API;
• mail.example.com — почтовый сервер;
• _sip._tcp.example.com — сервисная запись для SIP;
• _dmarc.example.com — политика DMARC для почты.

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

Из чего состоит DNS-запись: имя, тип, значение и TTL

Почти у любой DNS-записи есть несколько базовых полей.

1) Имя — домен или поддомен, к которому относится запись. Например, example.com, www.example.com, api.example.com. В интерфейсах DNS-провайдеров корневое имя зоны часто обозначается как @. Если зона — example.com, то запись с именем @ относится к example.com.

2) Тип — вид записи: A, AAAA, CNAME, MX, TXT, SRV и другие. Тип определяет, какое значение ожидается и как запись будет использоваться.

3) Значение — содержимое записи. Для A это IPv4-адрес, для AAAA — IPv6-адрес, для CNAME — другое доменное имя, для MX — почтовый сервер, для TXT — текстовая строка.

4) TTL — время жизни записи в кэше, обычно в секундах. Например, 3600 означает, что резолвер может кэшировать ответ один час. Высокий TTL снижает нагрузку на DNS и число запросов, но изменения распространяются дольше. Низкий TTL ускоряет переключение записей, но увеличивает число запросов.

TTL часто вызывает путаницу. Если вы изменили A-запись, это не значит, что весь интернет мгновенно увидит новый IP. Старое значение может оставаться в кэше у провайдеров, корпоративных DNS, браузеров и операционных систем. О задержках из-за кэша подробнее есть отдельный материал: «Как работает DNS caching и почему возникают странные задержки».

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

A и AAAA: куда указывает сайт

Записи A и AAAA связывают доменное имя с IP-адресом сервера.

A указывает на IPv4-адрес:

example.com.  3600  IN  A  203.0.113.10

AAAA указывает на IPv6-адрес:

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

Для обычного сайта A-запись отвечает на вопрос: «на какой сервер отправить пользователя, если он открыл example.com». Если сайт размещён на VPS, в A обычно указывают публичный IPv4-адрес сервера. Если сайт работает через CDN или облачную платформу, провайдер может выдать IP-адреса или попросить настроить CNAME.

У одного имени может быть несколько A-записей:

example.com.  3600  IN  A  203.0.113.10
example.com.  3600  IN  A  203.0.113.11

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

С AAAA ситуация похожая, но для IPv6. Если у сервера и сети корректно настроен IPv6, запись полезна. Если IPv6 на сервере указан в DNS, но фактически не работает, часть пользователей может столкнуться с задержками или ошибками подключения. Поэтому добавлять AAAA стоит только после проверки доступности по IPv6.

Типичные ошибки с A и AAAA:

1) Указан старый IP — сайт переехал на другой сервер, а DNS остался прежним. Пользователи попадают на старую копию сайта или видят ошибку.

2) IP указан с опечаткой — запись формально существует, но ведёт не туда.

3) Есть AAAA, но IPv6 не обслуживается — у части клиентов сайт открывается медленно или не открывается.

4) Изменили запись, но не учли TTL — владелец видит новый сайт, а часть пользователей ещё попадает на старый адрес.

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

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

CNAME создаёт псевдоним: одно доменное имя указывает не на IP-адрес, а на другое доменное имя.

Пример:

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

Это значит: если кто-то запрашивает www.example.com, нужно посмотреть записи для example.com.

CNAME часто используют для подключения внешних сервисов:

docs.example.com.  3600  IN  CNAME  example-docs.provider.net.

Так SaaS-платформа может сама менять IP-адреса на своей стороне, а владельцу домена не придётся обновлять DNS каждый раз.

Главное ограничение: на одном и том же имени CNAME не должен сосуществовать с большинством других записей. Если www.example.com — это CNAME, не нужно одновременно делать для www.example.com запись A, TXT или MX. Это нарушает логику DNS и может работать непредсказуемо.

Отдельный нюанс — корень домена. Для example.com классический CNAME обычно нельзя использовать, потому что на корне зоны уже есть обязательные записи вроде NS и SOA. Некоторые DNS-провайдеры предлагают аналоги: ALIAS, ANAME или CNAME flattening. В интерфейсе это может выглядеть как CNAME, но технически провайдер сам преобразует его в IP-ответы.

Когда выбирать CNAME, а когда A?

1) Используйте A — если у вас есть стабильный IP-адрес сервера.

2) Используйте CNAME — если подключаете внешний сервис, CDN, хостинг-конструктор, платформу документации или другой сервис, который выдаёт доменное имя.

3) Не ставьте CNAME без необходимости — лишний уровень DNS-резолвинга может усложнять диагностику. Это не проблема само по себе, но цепочки CNAME из нескольких переходов лучше избегать.

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

MX-запись указывает, какие серверы принимают почту для домена.

Пример:

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

Здесь письма на адреса вида user@example.com нужно доставлять на сервер mail.example.com. А сам mail.example.com уже резолвится в IP через A или AAAA.

У MX есть приоритет. Чем меньше число, тем выше приоритет:

example.com.  3600  IN  MX  10 mx1.example.net.
example.com.  3600  IN  MX  20 mx2.example.net.

Почтовый сервер отправителя сначала попробует mx1.example.net, а если он недоступен — mx2.example.net. Если приоритеты одинаковые, серверы могут использоваться примерно равноправно.

Для почты важно, чтобы MX указывал на доменное имя, а не напрямую на IP-адрес. Также у этого имени должна быть корректная A или AAAA-запись.

Частые ошибки с MX:

1) MX указывает на несуществующее имя — письма не доставляются или возвращаются с ошибкой.

2) Нет A-записи у почтового хоста — MX есть, но подключиться некуда.

3) Неправильные приоритеты — резервный сервер становится основным или наоборот.

4) Настроен только MX, но нет SPF/DKIM/DMARC — письма могут чаще попадать в спам или отклоняться.

MX отвечает только за маршрут входящей почты. За доверие к исходящим письмам отвечают другие механизмы, чаще всего через TXT: SPF, DKIM и DMARC. Если настраиваете доменную почту, пригодится разбор «SPF, DKIM и DMARC: как защитить домен от подделки писем».

TXT: текстовые записи для проверок и политик

TXT — универсальная текстовая запись. Изначально она была просто способом хранить произвольный текст в DNS, но на практике стала стандартным местом для подтверждений, политик безопасности и почтовых настроек.

Примеры TXT:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.example.net ~all"
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_acme-challenge.example.com.  300  IN  TXT  "token-for-certificate-validation"

Где используется TXT:

1) Подтверждение владения доменом — Google, Яндекс, GitHub, почтовые сервисы, CDN и SaaS-платформы часто просят добавить TXT с уникальным токеном. Если запись найдена, сервис понимает, что вы управляете доменом.

2) SPF — политика, какие серверы имеют право отправлять почту от имени домена. SPF хранится в TXT на корне домена.

3) DKIM — публичный ключ для проверки подписи письма. Обычно находится в записи вида selector._domainkey.example.com.

4) DMARC — политика обработки писем, которые не прошли SPF или DKIM. Обычно находится в _dmarc.example.com.

5) ACME-челленджи — подтверждение домена для выпуска SSL-сертификата, например через Let's Encrypt при DNS-валидации.

Главная особенность TXT: значение должно быть точным. Лишний пробел, неправильные кавычки, обрезанная строка или несколько конфликтующих SPF-записей могут сломать проверку.

Особенно часто встречается ошибка с SPF: у домена создают несколько TXT-записей, каждая начинается с v=spf1. Так делать не нужно. SPF-запись должна быть одна, а все разрешённые отправители объединяются в ней.

Например, плохо:

example.com.  TXT  "v=spf1 include:_spf.service1.net ~all"
example.com.  TXT  "v=spf1 include:_spf.service2.net ~all"

Лучше:

example.com.  TXT  "v=spf1 include:_spf.service1.net include:_spf.service2.net ~all"

SRV: где находится конкретный сервис

SRV-запись нужна, когда клиенту нужно узнать не просто IP-адрес, а сервис, протокол, порт и хост. Она часто используется в VoIP, SIP, XMPP, LDAP, Kerberos, Minecraft-серверах, некоторых корпоративных и сервис-дискавери-сценариях.

Формат имени у SRV обычно такой:

_сервис._протокол.домен

Например:

_sip._tcp.example.com.  3600  IN  SRV  10 60 5060 sipserver.example.com.

Поля значения:

• 10 — приоритет;
• 60 — вес;
• 5060 — порт;
• sipserver.example.com. — целевой хост.

Расшифровка: для сервиса sip по протоколу tcp в домене example.com нужно подключаться к sipserver.example.com на порт 5060.

Приоритет работает похоже на MX: меньше число — выше приоритет. Вес используется для распределения нагрузки между записями с одинаковым приоритетом. Чем выше вес, тем чаще клиент может выбирать этот вариант.

Пример с несколькими серверами:

_sip._tcp.example.com.  3600  IN  SRV  10 70 5060 sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10 30 5060 sip2.example.com.
_sip._tcp.example.com.  3600  IN  SRV  20 0  5060 sip-backup.example.com.

Здесь sip1 и sip2 — основные серверы с распределением по весам, а sip-backup — резервный.

Важно: SRV указывает на имя хоста, а не на IP. У целевого имени должна быть A или AAAA-запись. Также не все приложения поддерживают SRV. Браузер для обычного HTTP-сайта не будет искать _http._tcp.example.com, чтобы понять, на какой порт идти. Для сайтов обычно используют A, AAAA, CNAME, а порт задаётся протоколом или URL.

Если SRV-запись не работает, проверьте три вещи: правильное имя _service._proto, наличие точки или корректного FQDN в целевом значении и поддержку SRV на стороне клиента.

Как проверить DNS-записи

Проверять DNS-записи можно через веб-инструменты DNS lookup или из терминала. Для быстрой диагностики удобны dig и nslookup.

Примеры с dig:

dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig MX example.com
dig TXT example.com
dig SRV _sip._tcp.example.com

Чтобы посмотреть краткий ответ:

dig +short A example.com
dig +short MX example.com

Чтобы запросить конкретный DNS-сервер:

dig @8.8.8.8 A example.com
dig @1.1.1.1 A example.com

Это полезно, когда нужно понять, у всех уже обновилась запись или только у части резолверов.

nslookup тоже подходит:

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=SRV _sip._tcp.example.com

Подробные примеры есть в материалах «Утилита dig. Как проверить DNS-записи и отладить домен» и «nslookup: проверка DNS».

При проверке смотрите не только на факт наличия записи, но и на весь путь:

1) Какие NS-серверы авторитетны для домена — возможно, вы редактируете DNS не там. Например, домен зарегистрирован у одного провайдера, а NS указывают на Cloudflare или другой DNS-хостинг.

2) Что отвечает авторитетный сервер — это источник истины для зоны.

3) Что отвечают публичные резолверы — например, 8.8.8.8, 1.1.1.1 или DNS вашего провайдера.

4) Какой TTL у ответа — если видите старое значение, возможно, оно ещё живёт в кэше.

5) Нет ли цепочки CNAME — иногда проблема не в первой записи, а в следующем имени, на которое она указывает.

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

Типичные ошибки в DNS и как их избежать

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

1) Редактируют не ту DNS-зону — самая частая ситуация. В панели регистратора запись добавили, но домен использует NS другого провайдера. Проверяйте NS домена перед изменениями.

2) Путают @, пустое имя и полный домен — в одной панели нужно вводить @, в другой — example.com, в третьей — оставить поле пустым. Если ошибиться, можно получить запись не для example.com, а для example.com.example.com.

3) Добавляют точку не там — в DNS полное имя часто заканчивается точкой: mail.example.com.. Некоторые панели добавляют её сами. Если ввести значение неправильно, получится лишний суффикс зоны.

4) Создают конфликт CNAME — на одном имени не должны одновременно существовать CNAME и, например, A, TXT или MX.

5) Оставляют старые записи после миграции — сайт уже переехал, но старые A, AAAA, MX или TXT продолжают влиять на пользователей и сервисы.

6) Не снижают TTL перед миграцией — из-за этого часть пользователей дольше видит старую версию сайта.

7) Добавляют AAAA без проверки IPv6 — если сервер фактически не отвечает по IPv6, это может сломать доступность для части клиентов.

8) Не мониторят DNS как часть доступности — сайт может быть исправен на сервере, но недоступен из-за проблем с DNS. Поэтому DNS-проверки полезно сочетать с HTTP-мониторингом и проверками из разных точек.

В Statuser мониторинг доступности можно настроить с нужным интервалом: сервис будет регулярно проверять сайт и уведомлять о сбое. Это не заменяет ручную диагностику DNS, но помогает быстрее заметить, что после изменения записей что-то пошло не так. Для доменов также полезен подход из статьи «Мониторинг домена».

Хорошая практика перед изменениями: зафиксировать текущие записи, снизить TTL заранее, внести изменения, проверить ответы авторитетных DNS и публичных резолверов, затем посмотреть доступность сайта и почты. Если что-то сломалось, будет проще откатиться.

Краткая шпаргалка по основным DNS-записям

Если нужно быстро понять, какая запись нужна:

1) Сайт должен открываться по домену — чаще всего нужны A и, при наличии IPv6, AAAA.

2) Подключаете www — используйте CNAME на основной домен или A, если хотите указывать IP напрямую.

3) Настраиваете почту — нужны MX, а также TXT для SPF, DKIM и DMARC.

4) Подтверждаете домен в сервисе — почти всегда это TXT с токеном.

5) Сервис должен объявить порт и протокол — смотрите в сторону SRV.

DNS-записи лучше воспринимать не как разовую настройку, а как часть инфраструктуры. Они участвуют в деплоях, миграциях, выпуске сертификатов, доставке почты, подключении CDN и мониторинге доступности. Чем понятнее структура DNS-зоны, тем проще расследовать инциденты и менять инфраструктуру без простоя.

FAQ

Можно ли удалить старую DNS-запись сразу после миграции?
Лучше сначала убедиться, что новый маршрут работает, TTL старых ответов истёк, а мониторинг не показывает ошибок. После этого старые записи можно удалить.

Почему DNS-запись изменилась, но сайт всё ещё открывается по старому IP?
Скорее всего, старый ответ остался в кэше у резолвера, провайдера, операционной системы или браузера. Время зависит от TTL и поведения конкретных кэшей.

Нужна ли AAAA-запись каждому сайту?
Нет. Она нужна, если сервер или CDN действительно поддерживает IPv6. Если IPv6 не настроен, лучше не публиковать AAAA.

Чем CNAME отличается от редиректа?
CNAME работает на уровне DNS и подменяет имя при резолвинге. Редирект работает на уровне HTTP: браузер уже подключился к серверу и получил ответ 301 или 302.