Обычный CNAME на корне зоны несовместим с обязательными SOA и NS. Если сервис выдаёт только hostname, используйте ALIAS, ANAME или flattening у авторитетного DNS-провайдера: в панели останется цель, а клиент получит A и AAAA. Поддержка и ограничения зависят от провайдера.
Проблема появляется при подключении CDN, балансировщика или SaaS к адресу без www. Поставщик даёт edge.vendor.example, а панель DNS не принимает CNAME для example.com. Это корректный отказ: по RFC 1034 имя с CNAME не должно иметь другие данные. На вершине зоны уже есть SOA и NS; нередко там же находятся MX, TXT и CAA.
Что вернёт авторитетный сервер вместо CNAME
ALIAS, ANAME и flattening — функции авторитетного DNS-сервиса, а не стандартные типы ответа для клиента. Провайдер сам находит адреса целевого hostname и публикует для корня A и, если поддерживается, AAAA. Поэтому dig example.com CNAME может показать пустой ответ, даже когда в панели виден «псевдоним». Проверяйте тип ответа, который нужен клиенту, и не пытайтесь угадать конфигурацию панели по одному запросу.
| Что настроено | Запрос клиента | Ожидаемый ответ | Что проверить |
|---|---|---|---|
CNAME у www | www.example.com A | CNAME и адрес целевого имени | Цель и цепочку |
ALIAS/ANAME у @ | example.com A | A, синтезированный провайдером | Совпадение с актуальной целью |
Flattening у @ | example.com AAAA | AAAA, если цель и провайдер дают IPv6 | Отдельно A и AAAA |
| HTTP-редирект с корня | example.com A | Адрес сервера редиректа | HTTP 301/308 и TLS-сертификат |
Редирект решает задачу смены URL, а не динамического DNS-адреса. Если нужен именно корневой hostname в адресной строке, сравните ограничения конкретных DNS-сервисов. Базовые типы записей разобраны в справочнике DNS-записей.
Восемь провайдеров: что подтверждает документация
В таблице указаны функции, описанные в публичной документации на 13 ноября 2026 года. «Не описано» означает недостаток подтверждения, а не доказанный запрет во всех тарифах и интерфейсах. Наличие API-типа также не гарантирует, что кнопка есть в вашей версии панели.
| Провайдер | Путь для корня | Ограничение, которое важно до миграции |
|---|---|---|
| Cloudflare | CNAME flattening у apex по умолчанию | При proxy ответом будут адреса Cloudflare, при DNS-only — адреса цели; сломанная цель даёт NODATA. |
| Route 53 | Alias A/AAAA на поддерживаемый ресурс AWS или запись зоны | Не универсальный CNAME к произвольной цели; alias на CNAME внутри зоны у apex запрещён. |
| Yandex Cloud DNS | ANAME совместно с MX и TXT | Документация не советует ANAME для CDN-домена Yandex: возможен неверный географический узел. |
| Selectel DNS-hosting | В UI перечислены A/AAAA и CNAME, CNAME на домене второго уровня запрещён; API перечисляет ALIAS | В документации панели и API видны разные наборы типов. Уточните доступность ALIAS для своей зоны перед переносом. |
| Рег.ру | Документированы A для корня и CNAME для www | Подтверждения ALIAS/ANAME в проверенной инструкции нет; запросите его у поддержки, если цель динамическая. |
| DNSimple | ALIAS на hostname у apex | Авторитетный сервер возвращает A/AAAA; результат зависит от доступности целевого имени. |
| Azure DNS | Alias record set для поддерживаемых ресурсов Azure | Это ссылка на ресурс, а не обещание поддержки произвольного внешнего hostname. |
| DigitalOcean DNS | В проверенной инструкции для apex показан A с именем @ | CNAME описан для субдомена; универсальный ALIAS для корня в этой инструкции не подтверждён. |
Для российского стека чаще всего практический выбор — ANAME в Yandex Cloud DNS, обычный A у провайдера со статическим адресом либо переезд авторитетной зоны к сервису с flattening. При переносе NS сначала сохраните MX, TXT, CAA и DNSSEC-настройки: смена провайдера DNS затрагивает не только сайт. О порядке проверки делегирования см. команды dig.
Проверьте ответ до смены трафика
Сначала спросите каждый авторитетный NS, затем два независимых рекурсивных резолвера. Сравнивайте A и AAAA по отдельности. Пустой ответ на CNAME не является признаком поломки ALIAS. TTL в ответе может отличаться от TTL цели: провайдер управляет синтезированным ответом и своим обновлением адреса. Механизм кеширования и план переноса описаны в разборе TTL и диагностике распространения DNS.
dig +short NS example.com
dig @ns1.example.net example.com A +norecurse +noall +comments +answer
dig @ns1.example.net example.com AAAA +norecurse +noall +comments +answer
dig @1.1.1.1 example.com A +noall +comments +answer
dig @8.8.8.8 example.com A +noall +comments +answer
dig example.com MX +short
dig example.com TXT +shortВыполните команды со своими NS, а не с демонстрационными именами. Если авторитетные серверы расходятся, сначала исправьте зону; если они совпадают, а рекурсивные ответы нет, смотрите TTL и делегирование. В инструменте DNS enterno удобно сравнить публичный ответ, но авторитетный запрос остаётся обязательной контрольной точкой.
Что показал контрольный запрос к enterno.io
Мы запросили собственный домен напрямую у dns1.yandex.net 13 ноября 2026 года. Это пример обычной A-конфигурации: сервер вернул A и MX на одном имени, а на CNAME ответил NOERROR без записи. Он не доказывает, что enterno.io настроен через ALIAS. Он показывает, почему один пустой ответ на CNAME ничего не говорит о доступности сайта.
$ dig @dns1.yandex.net enterno.io A +norecurse +noall +answer
enterno.io. 3600 IN A 81.163.20.249
$ dig @dns1.yandex.net enterno.io MX +norecurse +noall +answer
enterno.io. 3600 IN MX 1 smtp.google.com.
$ dig @dns1.yandex.net enterno.io CNAME +norecurse +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr aa; QUERY: 1, ANSWER: 0Перед публикацией своей конфигурации повторите те же запросы к целевому hostname, сравните A/AAAA и проверьте TLS отдельно. Если DNS уже показывает нужный адрес, а сайт не открывается, продолжайте по маршруту диагностики DNS и HTTP.
Как сделан материал
Матрица собрана по официальным страницам восьми провайдеров 13 ноября 2026 года; тарифные ограничения, не описанные там, не выдумывались. SerpAPI сохранил Google US и Яндекс Москва; Wordstat региона 225 вернул пустой объект для точной фразы «cname на корневой домен», поэтому её частотность не объявлена нулевой. Контрольные команды выполнены с dig против публичного домена enterno.io, исходные stdout и exit code лежат в редакционном архиве. Аккаунты всех восьми провайдеров не тестировались; таблица о документированных функциях, а не о лабораторной проверке каждой панели.
Частые вопросы
Почему панель не принимает CNAME для @?
На вершине зоны есть SOA и NS. Обычный CNAME не должен сосуществовать с ними. Выберите поддерживаемый механизм ALIAS/ANAME/flattening либо A/AAAA.
Почему dig @ CNAME пустой, а сайт работает?
Авторитетный сервер может синтезировать A/AAAA из внутренней записи ALIAS или ANAME. Запросите A и AAAA; тип записи в панели нельзя надёжно восстановить по DNS-ответу.
Поддерживает ли Route 53 ALIAS на любой hostname?
Нет. Alias Route 53 привязан к поддерживаемым ресурсам AWS или записям зоны с ограничениями по типу. Для произвольной внешней цели проверьте требования вашего сервиса и используйте другой DNS-механизм.
Можно ли просто указать IP CDN вместо ALIAS?
Только если поставщик гарантирует стабильный адрес для корня. Временный IP из dig может измениться, а географическая маршрутизация CDN может нарушиться.
Источники
- RFC 1034: правило для CNAME
- Cloudflare: CNAME flattening
- AWS: Alias и CNAME в Route 53
- Yandex Cloud DNS: ANAME
- Selectel: типы записей DNS-хостинга
- Selectel DNS API: перечисление ALIAS
- DNSimple: ALIAS record
- Azure DNS: Alias records
- DigitalOcean: управление DNS-записями
- Рег.ру: типы ресурсных записей
