Обычную CNAME-запись нельзя поставить в корне DNS-зоны: этому имени уже нужны SOA и NS. Если платформа выдала имя вместо IP-адреса, для домена без www нужен поддерживаемый DNS-провайдером ALIAS/ANAME, CNAME flattening либо другая схема из инструкции платформы.
Начните с двух проверок: действительно ли вы меняете корень зоны и умеет ли ваш провайдер возвращать для него A/AAAA по имени цели. Надпись «CNAME» в панели ещё не означает, что такая же запись должна появиться в публичном DNS.
Почему CNAME для корневого домена не работает как для www
Корень зоны, или apex, — например, example.com, если зона называется example.com. В панели его часто обозначают @ или пустым полем имени; www.example.com — отдельный поддомен.
CNAME объявляет имя псевдонимом другого имени. Правило несовместимости с другими обычными данными у того же имени описано в RFC 1034, раздел 3.6.2; обязательные SOA и NS в корне зоны мешают использовать там обычный CNAME.
Не удаляйте SOA, NS, MX или TXT ради добавления псевдонима. Это не способ подключить сайт: можно нарушить работу зоны или почты. Ограничение касается корня любой зоны, в том числе отдельно делегированного поддомена.
Чем отличаются ALIAS, ANAME и flattening
Эти названия обозначают возможности конкретного DNS-провайдера, а не взаимозаменяемые настройки для любой панели. В типичной схеме провайдер получает адреса имени-цели и отвечает посетителю записями A/AAAA для вашего домена.
При CNAME flattening у Cloudflare возвращается конечный IP вместо CNAME. Поэтому отсутствие CNAME в ответе само по себе не доказывает ошибку: проверять нужно также A/AAAA.
Alias в Amazon Route 53 допускает корень зоны, но имеет ограничения на цели: например, выбранные ресурсы AWS или записи той же hosted zone. Перенести произвольное имя из инструкции конструктора в такой alias получится не всегда.
Включённое проксирование добавляет ещё один слой: DNS может отдавать адреса CDN, а не сервера сайта. Сравнивайте ответ с ожидаемой схемой провайдера, не требуйте буквального совпадения IP с целью.
Как проверить настройку по порядку
1. Найдите зону, которая обслуживает домен
Уточните NS у регистратора и сравните их с панелью, где внесена запись. Выполните dig example.com NS: это начальная проверка, а при спорном результате делегацию нужно сверить отдельно.
Сохраните текущие настройки для отката в приватном месте. Запишите имя цели, режим проксирования и требования платформы к привязке домена; не меняйте одновременно NS, почту и маршрутизацию сайта.
2. Проверьте цель и поддержку корня
В значении CNAME/ALIAS обычно нужно DNS-имя без https://, пути и порта. Убедитесь по документации панели, как она обрабатывает полное имя и завершающую точку.
Для иллюстрации ниже используются домены example.com и target.example.net. Замените их своим доменом и точным именем, выданным платформой; на результаты примера рассчитывать нельзя.
dig target.example.net A
dig target.example.net AAAA
dig example.com A
dig example.com AAAA
dig example.com CNAMEЕсли цель не даёт адресов, сначала разберите её настройку с платформой. При этом отсутствие AAAA допустимо для сервиса без IPv6: требовать одновременно обе версии IP не нужно.
3. Отделите авторитетный ответ от кеша
Запросите A и AAAA у каждого авторитетного NS, затем сравните ответы с резолвером проблемной сети. Шаблон команды для одного NS:
dig @ns.example.net example.com A +norecurse
dig @ns.example.net example.com AAAA +norecurseЗдесь ns.example.net нужно заменить реальным сервером зоны. Смотрите код ответа, флаг авторитетности AA, секции ответа и TTL; один только +short скрывает часть диагностической информации.
Если авторитетные серверы уже отвечают правильно, а резолвер ещё показывает прежний адрес, изучайте кеш и прежний TTL. Если нужных адресов нет уже на NS, ожидание «распространения DNS» не исправит неверную цель или неподдерживаемую настройку. Подробности — в статье почему DNS-записи не обновляются.
4. Проверьте сайт по исходному имени
Правильный DNS не гарантирует, что платформа приняла домен. Откройте HTTPS именно для example.com: проверьте сертификат, содержимое страницы и конечный адрес после перенаправлений.
Если открывается служебная страница или сертификат для другого имени, проверьте привязку домена и выпуск SSL на платформе. Схема «www работает, корень нет» разобрана в отдельном руководстве.
Что делать, если провайдер не поддерживает ALIAS
Используйте A/AAAA только с адресами, которые платформа официально разрешает применять для вашего домена. Не копируйте случайный IP из разового ответа цели: при его смене такая запись может устареть.
Другой вариант — использовать www с обычным CNAME, а корневой домен направить на сервис HTTP-перенаправления. Сам корень всё равно должен разрешаться в DNS и обслуживаться сервером; для перенаправления с HTTPS ему нужен подходящий сертификат. CNAME не создаёт HTTP-редирект.
Перенос DNS к другому провайдеру имеет смысл, если платформа требует схему, недоступную у текущего. До смены NS перенесите нужные записи и согласуйте DNSSEC: смена панели не должна обрывать почту или проверку подписей.
Как понять, что проблема устранена
Корень выдаёт ожидаемые адреса, HTTPS показывает нужный сайт без ошибки сертификата, а www приводит к выбранному основному адресу. Если IP динамические или используется CDN, разные адреса допустимы — важнее корректная маршрутизация и доступность.
После изменения регулярный мониторинг в Web-Puls поможет заметить повторную недоступность публичного URL. Он не заменяет проверку ALIAS в панели и не доказывает исправность всех сетей по одному успешному ответу.
Если ответы NS, настройки платформы и HTTPS противоречат друг другу, можно отправить заявку на диагностику. Укажите публичный домен, время сбоя с часовым поясом, DNS-провайдера и обезличенные результаты проверок; пароли, токены и доступ в кабинет в описание не добавляйте.