Если зациклился CNAME в DNS, нужно найти запись, которая возвращает цепочку к уже пройденному имени, и заменить ошибочную цель на подтверждённый адрес назначения. Очистка кэша или перезапуск сайта не исправят цикл в самой DNS-зоне.
Начните с точного имени, которое не открывается: например, поддомена www, API или адреса статических файлов. Затем выпишите каждое звено CNAME, подтвердите его на авторитетных серверах и только после этого меняйте запись.
Что считается циклом CNAME
CNAME — запись, которая делает одно DNS-имя псевдонимом другого. Обычная цепочка заканчивается именем с нужной записью, например A или AAAA; цикл возвращается к уже встреченному имени.
Условный пример, а не данные реального сайта:
www.example.com. CNAME edge.example.net.
edge.example.net. CNAME www.example.com.Бывает и прямой цикл: имя указывает само на себя. DNS-резолвер должен распознать такую ошибку; правило описано в RFC 1034, разделы 3.6.2 и 5.2.2.
Цепочка CNAME не является HTTP-редиректом: браузер ещё должен получить адрес сервера, прежде чем запросит страницу. Поэтому поиск правил 301/302 в CMS на этом этапе не поможет.
Шаг 1. Зафиксируйте ответ резолвера
На компьютере с утилитой dig запросите адреса проблемного имени. Замените пример своим полным DNS-именем; точка в конце обозначает абсолютное имя.
dig www.example.com. A
dig www.example.com. AAAA
dig www.example.com. CNAMEСохраните время проверки с часовым поясом, поле SERVER, status и секцию ANSWER. Не начинайте с +short: сокращённый вывод удобен для списка записей, но скрывает диагностический контекст.
Запрос типа CNAME показывает сам псевдоним и не обязан раскрывать весь путь до адреса. Успешный ответ на него не доказывает, что A/AAAA разрешаются.
При цикле резолвер может вернуть SERVFAIL, но этот код бывает и при других сбоях. Если повторяющееся имя пока не найдено, используйте общую диагностику DNS SERVFAIL, а не объявляйте причиной цикл.
Шаг 2. Пройдите цепочку вручную
Из ответа CNAME выпишите имя владельца записи и её цель. Запросите CNAME уже для цели и повторяйте проверку, ведя короткую таблицу:
| Проверяемое имя | Цель CNAME | Где получен ответ | | --- | --- | --- | | www.example.com. | edge.example.net. | NS зоны example.com | | edge.example.net. | www.example.com. | NS зоны example.net |
Возврат к имени из предыдущей строки — признак петли. Сравнивайте полные имена без учёта регистра и завершающей точки, чтобы не принять разное оформление за разные узлы.
Если CNAME закончился, отдельно запросите A и AAAA конечного имени. NXDOMAIN, отсутствие нужного типа записи или длинная цепочка без повторов — другие ситуации; сам по себе путь из нескольких псевдонимов ещё не является циклом.
Шаг 3. Подтвердите звенья на авторитетных NS
Кэш резолвера может содержать старую запись. Для каждого звена выясните, какая зона обслуживает это имя, и какие NS сейчас указаны в делегировании; поддомен может иметь собственную зону.
Запросите конкретную запись у каждого её авторитетного NS. В примере ниже NS условный: замените и сервер, и имя на значения своей зоны.
dig @ns1.example.com. www.example.com. CNAME +norecurseОпция +norecurse отключает запрос рекурсии, как описано в документации dig. Проверяйте флаг aa: ответ должен быть авторитетным для запрошенного имени; отсутствие aa требует уточнить сервер или делегирование.
Если цель находится в другой зоне, обращайтесь к NS именно той зоны. Один сервер не обязан знать всю цепочку, особенно когда она проходит через внешнего провайдера.
Цикл подтверждён, когда свежие авторитетные ответы образуют замкнутый путь. Если NS расходятся, сначала выясните, какая версия зоны правильная: смешанные ответы могут создавать петлю лишь для части запросов.
Шаг 4. Исправьте ошибочную цель, сохранив остальные записи
Перед изменением сохраните прежнее значение CNAME и TTL, проверьте историю изменений и актуальную инструкцию хостинга или CDN. Выберите звено, которым управляете, и согласуйте конечную цель с владельцем сервиса.
Не подставляйте случайный IP: внешний сервис может менять адреса и требовать свой hostname. Не добавляйте A/AAAA рядом с обычным CNAME на том же имени, чтобы «разорвать» цикл; замените неверный псевдоним корректной записью с учётом правил DNS-провайдера.
Если петля замыкается через чужую зону, передайте её владельцу конкретные пары «имя → цель» и время проверки. Без контроля этой зоны исправление её записи вам недоступно.
После сохранения повторите запросы к каждому авторитетному NS. Затем проверьте A/AAAA исходного имени через резолвер затронутой сети и другой доступный рекурсивный сервер.
Старые ответы могут сохраняться в кэшах до истечения их прежнего TTL; снижение TTL после сбоя не сокращает уже выданный срок. Поэтому фиксируйте отдельно: «зона исправлена» и «клиентский резолвер уже видит исправление».
Как проверить восстановление сайта
Работа завершена, когда авторитетные NS отдают согласованную цепочку без повторов, исходное имя получает ожидаемые адреса и нужная страница открывается по HTTPS. Проверьте также поддомены, от которых зависит страница: основной документ может работать, а API или файлы — оставаться недоступными.
Если адрес уже разрешается, но сайт не открывается, переходите к проверке TLS и HTTP. Не продолжайте менять DNS без нового доказательства ошибки.
Автоматический мониторинг в Web-Puls помогает заметить недоступность сайта после DNS-изменений, но не заменяет разбор каждого звена CNAME. Разовый успешный ответ также не подтверждает доступность во всех сетях.
Если цепочка проходит через несколько провайдеров и безопасная цель неясна, отправьте заявку на диагностику: укажите публичное имя, время сбоя и обезличенные ответы DNS. Специалист оценит симптомы и предложит план работ; пароли и ключи для первичного обращения не нужны.