Subdomain takeover: как предотвратить захват поддоменов и навести DNS‑гигиену

Если у компании десятки сервисов, микросервисов и кампаний, а в инфраструктуре используются сторонние платформы и хранение в облаках, риск subdomain takeover — не абстракция. Захват поддомена происходит тогда, когда DNS указывает на ресурс, которого уже нет (или он больше вам не принадлежит), а злоумышленник может создать или «подставить» одноименный ресурс на стороне провайдера. В результате запросы к вашему поддомену окажутся под его контролем — от фишинга и внедрения скриптов до кражи сессий и дискредитации бренда. Для фонового контекста по защите имени полезен материал о защите доменного бренда.

Что такое subdomain takeover простыми словами

Классическая картина: у вас был поддомен promo.example.com с записью CNAME на внешний сервис. Кампания закончилась, ресурс на стороне провайдера удалили — но DNS‑запись осталась. Теперь это «висящий» CNAME и типичный пример orphan records — сиротская запись, которая больше не соответствует реальности. Если платформа позволяет создать ресурс с тем же именем (и при этом проверка владения доменом не срабатывает), чужой пользователь может «поднять» ваш поддомен у себя.

Важно: subdomain takeover — это не про взлом вашего DNS. Ваши NS и зона остаются под контролем. Проблема в несоответствии DNS‑конфигурации фактическому состоянию внешних ресурсов и политике валидации у провайдеров.

Коротко о DNS‑механике, где здесь опасность

Упрощенная цепочка:

• Запись A/AAAA указывает на IP — обычно безопаснее, если IP под вашим контролем.
• Запись CNAME указывает на другое имя. Если это имя принадлежит внешнему сервису, вы зависите от его жизненного цикла и валидаций.
• Делегирование подзоны через NS — вы доверяете управление частью пространства имён другому провайдеру. Если делегированная зона исчезла на стороне провайдера, а ваша делегация осталась, появляется окно для ошибок конфигурации.

Сигналы потенциальной проблемы:

• Цепочка CNAME оканчивается доменом провайдера, который возвращает ошибку (например, HTTP‑страницу по умолчанию или сообщение об отсутствии проекта).
• Итоговое имя в цепочке CNAME не имеет записей A/AAAA (на резолв происходит NXDOMAIN или NOERROR/NODATA), но у вас в зоне запись все еще активна.
• Делегированная подзона в целом не обслуживается, но NS на неё установлен.

Как появляются orphan records и «висячие» CNAME

На практике сценариев много, и почти все — следствие организационных пробелов:

• Временные промо‑лендинги на сторонних конструкторах: лендинг удалили, запись CNAME забыли.
• Хранилища и статические хостинги: контейнер/бакет переименовали или удалили, а DNS остался на старое имя.
• Смена провайдера: сервис мигрировали, но стабильно забыли подчистить старые записи.
• Разделение окружений: dev, staging, preview живут в разных проектах; по завершении ветки ресурсы удаляются автоматически, а записи — нет.
• M&A и реорганизации: команды уходят, контракты закрываются, зоной владеет один отдел, внешними площадками — другой.
• Делегирование подзон: подзону на стороннем DNS отключили или не продлили тариф, а родительская зона продолжает её делегировать.

Ключевая мысль: угрозу порождает не сам CNAME, а рассинхрон процессов — когда жизненный цикл внешнего ресурса короче цикла управления DNS‑зоной.

Мифы и заблуждения

• «У нас есть HTTPS — значит, безопасно». Наличие SSL/TLS не мешает захватить поддомен, если домен указывает на чужой ресурс. Провайдер может выпустить сертификат на ваше имя, если контролирует ответы. Используйте надёжные SSL-сертификаты и следите за выпуском.
• «Ставим редирект на 404 — и все ок». 404 на вашем веб‑сервере помогает только если запрос приходит к вашему серверу. При subdomain takeover трафик уходит к чужому провайдеру.
• «CDN нас защитит». CDN без корректной конфигурации источника и проверки домена также может стать площадкой для «висячего» CNAME.
• «DNSSEC решает вопрос». DNSSEC защищает целостность ответа, а не корректность самой записи. Он не предотвращает dangling CNAME.

Оценка рисков: инвентаризация своих поддоменов

Первый шаг — перечень активов. Для собственной зоны это делается офлайн и безопасно: выгрузка зоны у регистратора/провайдера DNS, конвертация в машиночитаемый список и базовые проверки. Не забывайте про продление доменов и контроль контактных данных администратора — детали в материале о продлении доменов и периодах Grace/Redemption.

Что стоит включить в инвентаризацию:

• Полный список CNAME и делегированных подзон (NS на уровне поддомена).
• Карта зависимостей: на какие внешние домены указывает каждый CNAME.
• Источники правды: где создаются и изменяются записи — руками в панели, через Terraform, через API.
• Связанные сервисы: кто владеет ресурсами на стороне провайдера и какие процедуры удаления у них настроены.

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

На уровне DNS обратите внимание на:

• CNAME на домены, которыми вы не владеете.
• Длинные цепочки CNAME, особенно через несколько зон.
• Поддомены, делегированные через NS на сторонние серверы имён, которые не отвечают.
• Высокие TTL на «сомнительных» записях — усложняет оперативное выключение при инциденте.

На уровне HTTP/HTTPS без детализации вендорских «отпечатков» достаточно проверять, что запрашиваемый поддомен возвращает ожидаемую страницу вашего сервиса. Если приходит шаблонная страница провайдера или «ресурс не найден», это повод временно отключить запись и разобраться.

DNS‑гигиена: организационные практики

• Источник правды для DNS. Управляйте зонами как кодом (IaC), держите PR‑ы и ревью, автоматические проверки и историю изменений.
• Жизненный цикл и зависимость от внешних ресурсов. Любое удаление ресурса должно триггерить задачу на обновление/удаление DNS‑записей.
• Право собственности на домен у внешних сервисов. Используйте механизмы подтверждения владения (TXT‑валидации и т.п.) там, где это поддерживается.
• Минимизируйте «широкие» указатели. Избегайте «общих» CNAME на чужие платформы для множества поддоменов, если не контролируете выпуск ресурсов под каждым именем.
• Ограничивайте TTL для поддоменов, завязанных на внешних провайдеров: 300–900 секунд упростят реакцию.
• Процедура «санитации» зон. Ежеквартально проводите ревизию: что не обслуживается — удаляем или переводим на заглушку под вашим контролем.
• Делегирование подзон только при наличии SLA и мониторинга у провайдера DNS этой подзоны.

Технические проверки, которые полезно автоматизировать

1) Линт DNS‑зоны

Правила для CI, которые «ругаются», если:

• CNAME указывает на домен, не входящий в утвержденный список суффиксов.
• Делегированная подзона не отвечает на базовые запросы SOA/NS.
• Запись существует, но цепочка разрешения заканчивается на NXDOMAIN или NOERROR/NODATA.
• TTL превышает порог для внешних зависимостей.

2) Активные проверки доступности

Периодически опрашивайте конечные имена из CNAME цепочек и HTTP‑эндпоинты на предмет: неожиданной страницы провайдера, ответов по умолчанию, редиректов на внеплановые домены. Любая аномалия — повод перевести поддомен в «карантин» и открыть тикет.

3) Инвентаризация через API провайдера

Если внешняя платформа предоставляет API, синхронизируйте список активных ресурсов с вашими DNS‑записями. Любое расхождение — сигнал на разбор.

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

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

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

Набор безопасных команд для ручной проверки

Эти команды подходят для аудита собственных доменов и не содержат шагов по эксплуатации чужих:

dig +trace promo.example.com CNAME

dig promo.example.com CNAME +short

dig target.external-platform.example A +short

dig delegated.example.com NS +short

dig @ns1.delegated-dns.example SOA delegated.example.com

Логика простая: видите «висячий» CNAME или неотвечающую делегацию — снимаете запись, разбираетесь с владельцем сервисов. Это быстро, безопасно и снижает площадь атаки.

Инцидент: что делать, если поддомен уже «под вопросом»

Чек‑лист реакции без углубления в специфику отдельных платформ:

• Изоляция: временно отключите проблемную запись в зоне (удалите или переключите на заглушку под вашим контролем), установите короткий TTL и дождитесь экспирации кэшей.
• Коммуникации: уведомите службы безопасности, поддержку и владельца продукта, чтобы предупредить пользователей о возможных рисках.
• Восстановление: либо удалите запись окончательно, либо восстановите соответствующий ресурс у доверенного провайдера с подтверждением владения доменом.
• Проверка сертификатов: убедитесь, что по поддомену больше не выдается новый TLS‑сертификат сторонними лицами. Настройте оповещения о выпусках на ваши имена у используемых вами центров сертификации и используйте актуальные SSL-сертификаты.
• Пост‑мортем: исправьте процесс, который допустил появление «висячей» записи.

Практики проектирования, снижающие риск

• Явная привязка ресурсов. Предпочитайте A/AAAA на IP, который контролируете, если нет строгой необходимости в CNAME на внешние домены.
• Контролируемые суффиксы. Если нужен CNAME на внешнюю платформу, используйте выданное под вас уникальное имя, которое нельзя повторно занять третьими лицами без валидации.
• Глобальные заглушки. Держите под своим управлением «паркинг» для временно неиспользуемых поддоменов, чтобы исключить наплыв трафика к сторонним провайдерам.
• Чёткая модель владения. У каждого поддомена должен быть ответственный владелец (team owner), SLA и срок пересмотра.
• Ревью архитектуры. Любое делегирование NS — только после архитектурного ревью и мониторинга доступности зоны.

Регулярные проверки: как встроить в процесс

Настройте еженедельную задачу, которая:

• Собирает все CNAME и делегированные подзоны из вашей зоны.
• Разрешает цепочки до A/AAAA и проверяет, что конечная точка существует и отвечает.
• Выполняет HTTP‑запрос к корню поддомена и сверяет контент с эталоном (например, по заголовку Server или наличию уникального признака).
• Создаёт тикеты с пометкой «высокий приоритет» на все случаи рассинхронизации.

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

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

Подробнее

Частные случаи: на что обратить внимание

Делегирование подзон

При делегировании NS для app.example.com убедитесь, что:

• У провайдера включены оповещения о недоступности зоны и истечении подписки.
• В вашем мониторинге есть проверки SOA и ответов авторитетных NS.
• Есть план отката: возможность быстро снять делегирование и перевести критичные записи в родительскую зону временно.

Вайлдкарды

*.example.com — мощный, но опасный инструмент. Не указывайте вайлдкард CNAME на внешние платформы, где вы не контролируете выпуск ресурсов. Лучше ограничить список явно используемых поддоменов.

Смена провайдера

Перед миграцией составьте карту соответствий «старый ресурс → новый ресурс». Поднимите временные заглушки под вашим контролем, уменьшите TTL, а после переезда выполните «санитацию»: удалите старые записи, удалите/закройте ресурсы на стороне прежнего провайдера, убедитесь в отсутствии остаточных зависимостей.

Ответы на частые вопросы

Поможет ли запрет автоиндексации или редирект на основной домен? Это меры удобства и частично бренда, но не защита от takeover. Если запись указывает на сторонний ресурс, он может обслужить ваш трафик без участия вашей инфраструктуры.

Стоит ли массово переводить все CNAME на A/AAAA? Не всегда. CNAME — нормальный инструмент, но для внешних зависимостей нужны процессы жизненного цикла и автоматические проверки. Там, где возможно, используйте имена под вашим контролем.

Можно ли «закрепить» имя так, чтобы его никто не занял? Это зависит от политики провайдера. Ваша сторона — не оставлять сиротских записей и использовать верификацию владения доменом, где это доступно. При необходимости зарегистрируйте дополнительные зоны и суббренды через регистрацию доменов, а также держите домены в актуальном статусе.

Итог: subdomain takeover — организационная проблема, решается процессами

Технически захват поддомена редко выглядит как «взлом» — это следствие разрыва между жизненным циклом ресурсов и управлением DNS. Выстроенная DNS‑гигиена, инвентаризация, автоматические проверки в CI/CD и дисциплина при деактивации внешних сервисов закрывают подавляющее большинство сценариев. Начните с малого: выгрузите зону, соберите карту CNAME и делегаций, внедрите линт, заведите владельцев для поддоменов и запланируйте регулярную «уборку». Этого достаточно, чтобы перестать думать о subdomain takeover как о «черном лебеде» и превратить его в управляемый операционный риск.