Если CNAME указывает на удалённый сервис, сначала подтвердите, что ресурс действительно выведен из эксплуатации. Затем удалите ненужный алиас из действующей DNS-зоны или замените его на адрес сервиса, которым вы управляете.
Очистка кэша не исправит запись, оставшуюся на авторитетном DNS-сервере. А ответ 404 или страница «проект не найден» ещё не доказывают удаление: причиной может быть потерянная привязка домена на работающей платформе.
Что именно осталось после удаления сервиса
CNAME — DNS-алиас: он связывает одно имя с другим, а не с URL страницы. Например, учебный поддомен promo.example.com мог вести на площадку для лендингов; проект удалили, но запись в зоне сохранилась.
Такую ссылку называют dangling DNS — «висячей» DNS-записью. Если провайдер позволяет другому аккаунту заново занять её цель и подключить ваш домен без достаточной проверки владения, возникает риск перехвата поддомена. Это зависит от правил платформы, а не от одного факта наличия CNAME; сценарий и меры защиты описаны в документации Microsoft.
1. Найдите запись в действующей зоне
Проверьте NS домена и сопоставьте их с DNS-панелью, где собираетесь менять запись. Для поддомена с отдельным делегированием нужна его собственная зона, а не автоматически зона основного домена.
Если установлен dig, выполните запросы, подставив своё публичное имя. Команды читают DNS и ничего не меняют:
dig promo.example.com CNAME
dig promo.example.com A
dig promo.example.com AAAAСохраните статус ответа, имя цели, TTL и время проверки. Не ограничивайтесь коротким выводом: пустая строка не показывает, был ли ответ об отсутствии имени, тайм-аут или отказ сервера.
Для сравнения запросите CNAME напрямую у каждого авторитетного NS активной зоны: dig @ns.example.net promo.example.com CNAME +norecurse. Здесь ns.example.net — учебный адрес; замените его реальным NS и проверьте флаг aa, подтверждающий авторитетный ответ. Параметры запроса описаны в руководстве BIND.
2. Проследите цепочку и подтвердите удаление
Возьмите имя из ответа CNAME и отдельно запросите для него CNAME, A и AAAA. Если появился следующий алиас, повторяйте проверку до конечной цели, отмечая каждое имя.
Правило следования CNAME описано в RFC 1034, раздел 3.6.2. Важно исследовать всю цепочку: первый переход может вести на ваш действующий домен, а забытая внешняя ссылка находиться дальше.
Как читать результат
- Цель отвечает NXDOMAIN. На момент запроса это имя не существует по ответу DNS; выясните, почему оно исчезло, прежде чем считать удаление намеренным.
- Адреса есть, но платформа не узнаёт поддомен. Проверьте привязку custom domain и наличие проекта в своём аккаунте. Общий IP платформы не подтверждает, что ресурс принадлежит вам.
- Имена в цепочке повторяются. Это петля CNAME, отдельная неисправность, а не доказательство удаления сервиса.
- Ответы разных NS расходятся. Сначала разберите рассинхронизацию зоны; изменение только одного сервера не даёт завершённого исправления.
Подтвердите состояние проекта в своём кабинете провайдера или через его поддержку: существует ли ресурс, какой аккаунт им управляет и какой адрес сейчас рекомендован для подключения. Не пытайтесь регистрировать чужую цель для проверки возможности перехвата.
3. Выберите удаление или перенос
Если поддомен больше не нужен, удалите именно его CNAME. Перед этим проверьте ссылки в сайте, рекламных материалах, интеграциях и настройках авторизации: старое имя может всё ещё использоваться.
Если адрес нужно сохранить, сначала подготовьте новый ресурс под своим контролем: привязку домена, ожидаемую страницу и выпуск сертификата по правилам платформы. После этого замените CNAME на подтверждённую цель и проверьте выдачу; не подставляйте найденный IP общего хостинга наугад.
DNS-алиас не создаёт HTTP-редирект. Если посетителя нужно перевести со старого адреса на новый URL, необходим работающий HTTPS-узел для старого имени, который отдаст перенаправление; одна замена CNAME этого не обеспечивает.
Сохраните прежнее значение для расследования, но не возвращайте его автоматически при неудачном переносе: цель уже могла выйти из-под вашего контроля. Для будущего вывода сервиса из эксплуатации включите снятие DNS-привязки в план работ до удаления ресурса.
4. Проверьте результат за пределами панели
Сначала повторите прямой запрос ко всем авторитетным NS, затем сравните ответы используемого и другого рекурсивного резолвера. Уже сохранённый CNAME может оставаться в кэше до истечения прежнего TTL; снижение TTL после изменения не очищает чужие кэши. Подробнее — в разборе задержек обновления DNS.
При удалении убедитесь, что старая цель больше не возвращается: отсутствие CNAME не обязательно означает NXDOMAIN, если остались другие записи или действует wildcard. При переносе откройте исходный поддомен по HTTPS и проверьте сертификат, HTTP-код и ожидаемое содержимое, а не только наличие ответа 200.
Для оставленного в работе URL можно использовать регулярный мониторинг Web-Puls. Проверка доступности помогает заметить сбой, но не доказывает владение внешним ресурсом и не заменяет ревизию DNS-привязок.
Когда передать задачу специалисту
Если неизвестен владелец цели, появился чужой контент или непонятно, какие интеграции используют поддомен, отправьте заявку на диагностику. Укажите публичное имя, цепочку CNAME, время с часовым поясом и последние изменения; не передавайте пароли, токены или пользовательские данные. Специалист оценит задачу и предложит формат работ.