CNAME apex, A record, ALIAS и ANAME: что выбрать для домена в 2026

В DNS есть несколько тем, которые выглядят простыми, пока не приходится подключать домен к CDN, SaaS-платформе, балансировщику или динамически меняющейся инфраструктуре. Одна из таких тем — что делать с корнем домена, если сервис просит указать CNAME. Для поддомена всё понятно: www.example.ru можно направить на example.platform.net. А вот с example.ru, то есть с apex-зоной, начинаются нюансы.

В 2026 году ситуация лучше, чем десять лет назад: многие DNS-провайдеры умеют ALIAS, ANAME или CNAME flattening. Но базовые правила DNS никуда не исчезли. Если не понимать, что именно делает ваша панель, легко получить странные симптомы: сайт открывается только с www, почта перестаёт принимать письма, SSL-выпуск не проходит проверку, а часть пользователей видит старый IP дольше ожидаемого.

Разберём, чем отличаются A record, CNAME, ALIAS и ANAME, почему cname apex — не просто «ещё одна запись», и какой вариант выбрать для обычного сайта, CDN, SaaS и собственной инфраструктуры.

Коротко: что такое apex и почему вокруг него столько ограничений

Apex, zone apex, naked domain, bare domain, корень зоны — это имя самой DNS-зоны без дополнительного поддомена. Если зона называется example.ru, то apex — это example.ru. В файлах зоны его часто обозначают символом @.

В корне зоны почти всегда живут служебные записи: SOA, NS, часто MX, TXT для SPF/DMARC, CAA, иногда записи для верификации сервисов. Из-за этого обычный CNAME в apex конфликтует с самой моделью DNS.

Главное правило: имя с CNAME не должно иметь других записей. А корень зоны обязан иметь как минимум SOA и NS. Поэтому классический CNAME на apex по стандартной логике DNS невозможен.

Это не прихоть конкретного регистратора и не ограничение панели. Если DNS-сервер позволяет создать настоящий CNAME для @ рядом с MX, NS и SOA, он либо нарушает ожидания резолверов, либо под капотом делает не CNAME, а flattening — то есть подменяет тип записи на адресные ответы.

A record: самый понятный и предсказуемый вариант

A record связывает имя с IPv4-адресом. Для IPv6 используется AAAA. Это базовый и наиболее совместимый способ указать, куда должен вести домен.

example.ru. 300 IN A 203.0.113.10
example.ru. 300 IN AAAA 2001:db8:10::10
www.example.ru. 300 IN CNAME example.ru.

Такой вариант хорошо подходит, если у сайта есть стабильный IP: виртуальный сервер, выделенный балансировщик, reverse proxy, собственный веб-сервер или панель хостинга, которая выдаёт фиксированный адрес. Поведение понятно: авторитативный DNS отвечает IP-адресом, резолвер кэширует его на время TTL, браузер подключается к этому адресу.

Плюсы A record — простота диагностики, совместимость и прозрачный контроль. Минусы — вам нужно менять запись при смене IP. Если инфраструктура управляется сторонним сервисом и IP может меняться автоматически, ручное обслуживание A/AAAA становится слабым местом.

Когда выбирать A/AAAA

• Сайт размещён на собственном сервере, VDS или хостинге с постоянным IPv4/IPv6.
• Вы контролируете балансировщик и знаете его адреса.
• Нужна максимальная предсказуемость при миграциях и аварийных переключениях.
• Почта, TXT-записи, DNSSEC и CAA должны работать без сюрпризов.

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

CNAME: удобно для поддоменов, опасно для корня

CNAME говорит: это имя является каноническим псевдонимом другого имени. Резолвер сначала получает целевое имя, затем запрашивает его адресные записи.

www.example.ru. 300 IN CNAME example.platform.net.
example.platform.net. 60 IN A 198.51.100.20
example.platform.net. 60 IN A 198.51.100.21

Для www, app, cdn, static, docs и других поддоменов это нормальная практика. Владелец платформы может менять IP у себя, а ваш DNS остаётся неизменным. Именно поэтому SaaS-сервисы любят просить CNAME: они получают гибкость маршрутизации, а клиенту не нужно следить за адресами.

Но для корня зоны настоящий CNAME почти всегда плохая идея. Даже если панель его принимает, проверьте, что происходит на самом деле. Если имя example.ru стало CNAME, рядом с ним не должны существовать MX, TXT, CAA, NS и SOA. А без них нормальная зона жить не может.

Типичный конфликт CNAME apex

example.ru. 3600 IN SOA ns1.example.ru. hostmaster.example.ru. 2026010101 3600 900 1209600 300
example.ru. 3600 IN NS ns1.example.ru.
example.ru. 3600 IN MX 10 mail.example.ru.
example.ru. 300 IN CNAME example.platform.net.

Такую комбинацию не стоит считать рабочей конфигурацией. В одних системах запись не сохранится, в других появится предупреждение, в третьих будет выполнено «уплощение» CNAME, а пользователь увидит не CNAME, а A/AAAA. Разница принципиальная: в первом случае вы нарушаете правила, во втором — используете специальную функцию провайдера.

ALIAS record: псевдоним, который отвечает адресами

ALIAS — это не классический тип записи из базового DNS-стандарта в том же смысле, что A, AAAA или MX. Обычно это функция DNS-провайдера: вы указываете доменное имя-цель, а авторитативный сервер сам периодически резолвит его и отдаёт клиентам готовые A и/или AAAA.

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

@ 300 ALIAS example.platform.net.

Реальный ответ для клиента будет похож на такой:

example.ru. 300 IN A 198.51.100.20
example.ru. 300 IN A 198.51.100.21

Именно поэтому alias record часто применяют для корня домена при подключении к CDN, облачному балансировщику или SaaS, где нельзя закрепить один вечный IP. Для пользователя и большинства резолверов это выглядит как обычный A record, а администратор получает удобство, близкое к CNAME.

Важные ограничения ALIAS

У ALIAS нет единого поведения у всех провайдеров. Отличаться может всё: как часто обновляются адреса цели, учитывается ли TTL целевого имени, поддерживается ли IPv6, что происходит при временной недоступности резолвинга, можно ли использовать запись вместе с DNSSEC, видит ли API эту запись как отдельный тип или как синтетический A.

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

ANAME: та же идея, но с другими реализациями

ANAME решает ту же задачу, что и ALIAS: позволяет указать имя-цель там, где классический CNAME использовать нельзя или неудобно. В разных DNS-системах ANAME может быть отдельной синтетической записью, внутренним объектом зоны или механизмом автоматического обновления A/AAAA.

На практике для администратора вопрос обычно звучит так: «Могу ли я направить apex на имя платформы и при этом сохранить MX, TXT, CAA и NS?» Если ответ да, а наружу отдаются адресные записи, то это подходящий механизм независимо от названия — ALIAS, ANAME или flattening.

Но не стоит переносить конфигурацию между провайдерами вслепую. Если в старой панели была запись ANAME, в новой она может называться ALIAS, Flattened CNAME или вообще не поддерживаться. При миграции зоны такие записи нужно проверять вручную, а не только импортировать BIND-файл.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

CNAME flattening: почему это не совсем CNAME

CNAME flattening — популярное название механизма, при котором DNS-провайдер разрешает вам указать CNAME-подобную цель, но клиентам возвращает адреса. Это особенно полезно для apex, потому что внешне зона остаётся корректной: у корня есть SOA, NS, MX, TXT, а веб-трафик получает A/AAAA.

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

В мониторинге flattening может выглядеть обманчиво. Команда dig example.ru CNAME не покажет CNAME, потому что его действительно нет в публичном ответе. Нужно проверять A, AAAA, авторитативные серверы и совпадение с целевой платформой.

dig example.ru A
dig example.ru AAAA
dig example.platform.net A
dig example.platform.net AAAA

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

Сравнение A, CNAME, ALIAS и ANAME

Для быстрой ориентации полезно держать в голове не названия, а поведение записей.

• A record и AAAA указывают непосредственно на IP-адреса. Это стандартно, прозрачно и стабильно.
• CNAME указывает на другое имя. Отлично подходит для поддоменов, но не должен использоваться в apex как настоящая DNS-запись.
• ALIAS обычно хранит имя-цель в панели, а наружу отдаёт адресные записи. Подходит для apex, если реализация провайдера надёжна.
• ANAME близок к ALIAS по назначению, но детали зависят от DNS-сервиса.
• CNAME flattening — общее название идеи «указать имя, ответить адресами».

Если упростить до практического правила: для поддомена используйте CNAME, для корня со стабильным IP — A/AAAA, для корня с динамической платформенной целью — ALIAS, ANAME или flattening.

Как выбрать запись для типовых сценариев

Обычный сайт на сервере или хостинге

Если у вас есть конкретный IP-адрес веб-сервера, используйте A и при наличии IPv6 — AAAA. Это типичный вариант для проекта на виртуальном хостинге, VDS или собственном reverse proxy. Поддомен www можно сделать CNAME на корень или, наоборот, корень вести на IP, а www — на тот же IP.

@ 300 A 203.0.113.10
@ 300 AAAA 2001:db8:10::10
www 300 CNAME example.ru.

На веб-сервере затем настройте канонический редирект: либо с www на apex, либо наоборот. DNS не заменяет HTTP-редиректы и не сообщает поисковым системам, какой вариант считать главным.

CDN или SaaS просит CNAME для корня

Если сервис в инструкции пишет «создайте CNAME для example.ru», не спешите. Проверьте, поддерживает ли ваша DNS-панель ALIAS, ANAME или flattening. Если да, укажите целевое имя там. Если нет, варианты зависят от платформы: иногда можно использовать www как основной домен и сделать редирект с apex, иногда сервис выдаёт фиксированные IP, иногда лучше перенести авторитативный DNS к провайдеру, который умеет flattening.

Самый неудачный вариант — попытаться силой создать настоящий CNAME на apex и надеяться, что «как-нибудь заработает». Оно может заработать для сайта, но сломать почту, верификацию домена или выпуск сертификатов.

Почтовый домен

Для домена, на котором работает почта, особенно важно не ломать apex. Записи MX, SPF в TXT, DMARC, DKIM-селекторы и верификационные TXT должны оставаться доступными. Поэтому настоящий CNAME на корне здесь недопустим. Используйте A/AAAA или синтетический ALIAS/ANAME, который не мешает другим типам записей.

Мультиарендный SaaS с доменами клиентов

Если вы сами строите SaaS и просите клиентов подключать домены, старайтесь давать две понятные инструкции: для поддомена — CNAME, для apex — ALIAS/ANAME/flattening или фиксированные адреса балансировщика. Если клиентам нужно делегировать отдельную часть зоны, пригодится отдельный разбор про делегирование поддомена на NS-серверы.

Хорошая практика — поддерживать оба варианта: customer.example.com через CNAME и example.com через адресные записи или ALIAS. Тогда меньше обращений в поддержку и меньше поломок при переносе DNS.

TTL: почему низкое значение не всегда спасает

TTL показывает, как долго резолверы могут кэшировать ответ. При обычной A record логика простая: поставили 300 секунд — большинство резолверов обновит запись примерно через пять минут после истечения старого кэша. В реальном мире бывают отклонения, но модель понятна.

С ALIAS и ANAME появляется второй слой. Есть TTL, который видит клиент для вашего домена, и есть TTL целевого имени, которое резолвит DNS-провайдер. Если провайдер обновляет синтетические адреса раз в несколько минут, снижение публичного TTL до 60 секунд не даст мгновенного переключения. Пользователи будут быстро запрашивать ваш DNS заново, но сам ответ может оставаться старым.

Перед миграцией лучше заранее протестировать фактическое время реакции. Не в день релиза, а на тестовой записи. Например: создайте test-alias.example.ru, направьте его на имя, адрес которого вы контролируете, поменяйте адрес цели и измерьте, когда авторитативные серверы начнут отдавать новый IP.

DNSSEC, CAA и SSL: что проверить заранее

С DNSSEC синтетические записи требуют аккуратной реализации. Авторитативный DNS должен корректно подписывать ответы, которые он генерирует из ALIAS или ANAME. У крупных DNS-провайдеров это обычно решено, но при самостоятельном DNS или редкой панели стоит проверить валидирующим резолвером.

CAA важна для выпуска SSL-сертификатов. Если вы ограничиваете центры сертификации через CAA, убедитесь, что запись остаётся на apex и видна извне после настройки ALIAS/ANAME. Никакая веб-маршрутизация не поможет, если проверка сертификата упирается в некорректный DNS.

example.ru. 300 IN CAA 0 issue "ca.example"
example.ru. 300 IN TXT "v=spf1 mx -all"
example.ru. 300 IN MX 10 mail.example.ru.

При подключении CDN или SaaS также проверьте, где завершается TLS. Если сертификат выпускает платформа, ей нужно подтвердить владение доменом. Иногда для этого требуется отдельный TXT или CNAME на поддомене валидации. Эти записи не конфликтуют с ALIAS на apex, если настроены правильно.

Если вы автоматизируете выпуск wildcard-сертификатов через DNS, посмотрите практику DNS-01 для wildcard SSL: она помогает заранее понять, какие TXT-записи должны оставаться управляемыми.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как диагностировать: что спрашивать у DNS, а не у браузера

Браузер показывает только итог: сайт открылся или нет. Для DNS-диагностики лучше начинать с авторитативных серверов и конкретных типов записей.

dig example.ru NS
dig example.ru SOA
dig example.ru A
dig example.ru AAAA
dig example.ru MX
dig example.ru TXT
dig www.example.ru CNAME

Если есть подозрение на кэш, запросите конкретный авторитативный сервер. Так вы увидите, что реально опубликовано в зоне, минуя промежуточные резолверы.

dig @ns1.example-dns.test example.ru A
dig @ns1.example-dns.test example.ru MX
dig @ns1.example-dns.test example.ru CNAME

Для apex с flattening нормальная картина — есть A/AAAA, нет публичного CNAME, при этом в панели указана CNAME-подобная цель. Для настоящего поддомена с CNAME нормальная картина — запрос CNAME показывает целевое имя, а запрос A может вернуть итоговые адреса после рекурсивного разрешения.

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

Ошибка 1: «Удалю MX, чтобы поставить CNAME»

Так делать нельзя, если домен используется для почты. Удаление MX не просто «освобождает место» для CNAME — оно меняет почтовую маршрутизацию домена. Даже если почта физически живёт на другом сервере, отправители ориентируются на DNS.

Ошибка 2: «Поставлю CNAME на @, потому что сервис так написал»

Инструкции SaaS часто универсальны и не учитывают особенности apex. Для корня ищите раздел про naked domain, apex, ALIAS, ANAME или CNAME flattening. Если его нет, уточняйте у поддержки сервиса, какие варианты поддерживаются.

Ошибка 3: «ALIAS есть, значит всё будет мгновенно»

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

Ошибка 4: «DNS-редиректит с www на без www»

DNS не делает HTTP-редиректы. Он только отвечает, в какие адреса или имена нужно идти. Канонический домен, 301/308-редиректы, HSTS и SEO-склейка настраиваются на уровне веб-сервера, CDN или приложения.

Ошибка 5: «AAAA не нужна, IPv6 всё равно мало кто использует»

В 2026 году IPv6 уже нельзя считать экзотикой. Если целевая платформа поддерживает IPv6, проверьте, отдаёт ли ваш ALIAS/ANAME синтетические AAAA. Если не поддерживает — лучше явно понимать это ограничение, а не обнаружить его по жалобам пользователей из отдельных сетей.

Практическая матрица выбора на 2026 год

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

• Корень домена на собственный сервер: A и по возможности AAAA.
• www на тот же сайт: CNAME на apex или отдельные A/AAAA, если так удобнее панели.
• Поддомен на SaaS: CNAME.
• Apex на SaaS/CDN без фиксированного IP: ALIAS, ANAME или flattening.
• Домен с активной почтой: избегать настоящего CNAME на apex, обязательно сохранять MX и нужные TXT.
• Критичная миграция: заранее снижать TTL и тестировать фактическое обновление, а не только смотреть значение в панели.

Если домен ещё не куплен, полезно заранее проверить, где будет DNS, поддерживает ли панель нужные типы записей и удобно ли управлять CAA/TXT. На странице регистрации доменов можно подобрать доменную зону, а технические требования к DNS лучше зафиксировать до запуска проекта.

Для большинства проектов эта матрица закрывает 95% случаев. Оставшиеся 5% — геораспределённый DNS, weighted routing, failover, split-horizon, DNSSEC-автоматизация и сложные CDN-схемы — требуют отдельного проектирования, но базовое правило остаётся тем же: не подменяйте стандартный CNAME на apex надеждой, что резолверы «поймут как надо».

Итог: названия разные, проверять нужно поведение

A record — это прямой адрес. CNAME — псевдоним имени, хороший для поддоменов и плохой для корня зоны. ALIAS и ANAME — практичные механизмы для apex, когда нужно сослаться на имя платформы, но наружу отдавать адресные записи. В 2026 году они стали обычным инструментом, но всё ещё зависят от реализации конкретного DNS-провайдера.

Если нужно принять решение быстро, задайте себе три вопроса. Первый: это apex или поддомен? Второй: у цели есть стабильный IP или только доменное имя? Третий: есть ли на домене почта, TXT-верификации, CAA и DNSSEC? Ответы почти всегда приведут к правильному выбору.

А перед важной миграцией не ограничивайтесь тем, что запись «сохранилась в панели». Проверьте ответы авторитативных NS, публичные A/AAAA, наличие MX и TXT, поведение TTL и выпуск SSL. DNS редко ломается громко; чаще он работает «почти правильно», и именно это создаёт самые неприятные инциденты.