NS-записи домена подменили: признаки и порядок восстановления

MAATRIX

Сайт вдруг открывается не тем, чем должен, почта перестаёт ходить, а dig на ваш домен возвращает серверы имён, которых вы никогда не заказывали, — это не сбой хостинга и не опечатка в конфиге. Это симптомы одного из самых тяжёлых инцидентов в инфраструктуре: у вас увели контроль над NS-записями домена. Дальше — что это значит на практике, как отличить такую атаку от обычного технического сбоя и что делать в первые часы, чтобы вернуть домен и не потерять на этом почту, репутацию и клиентов.

Почему захват NS-записей — это не «упал один сайт»

NS-записи (name server records) — это делегирование домена: они говорят всему интернету, к какому DNS-серверу идти за ответом на запрос A, MX, TXT и любой другой для вашего домена. Если NS-записи в реестре регистратора поменяли на чужие серверы, атакующий получает не доступ к одному сервису, а полный контроль над всем, что резолвится через этот домен:

• Веб-сайт. Атакующий может поднять фишинговую копию на своём хостинге и подменить A/AAAA-записи так, что посетители попадут именно туда — с валидным доменным именем в адресной строке.
• Почта. Меняя MX, можно перехватывать входящую почту целиком: письма с кодами восстановления паролей от других сервисов, переписку с клиентами, счета.
• Любые сервисы, завязанные на домен. SSO, API с проверкой домена, вебхуки, интеграции — всё, что доверяет DNS-имени, автоматически доверяет и тому, кто им управляет.
• TLS-сертификаты. Через контроль над DNS или почтой на этом домене атакующий может пройти проверку домена (DNS-01 или email-подтверждение) у любого центра сертификации и выпустить валидный сертификат на ваше имя. Разница между Let's Encrypt и обычным доменным сертификатом здесь только в механике — оба верят в то, что владеет доменом тот, кто отвечает на DNS-запросы; подробнее о механизме проверки — в статье о том, как Let's Encrypt доказывает, что домен ваш.

Отсюда и практический вывод: если взломали один VPS, вы теряете один сервис. Если увели NS-записи домена — вы теряете всё, что на этот домен завязано, причём одновременно и без предупреждения.

Как домен захватывают на практике

Технически атака происходит не через DNS-сервер и не через хостинг — она происходит через аккаунт у регистратора. Пути обычно два:

1. Компрометация учётной записи регистратора. Утёкший или подобранный пароль, переиспользованный с другого сервиса, доступ к почте, на которую зарегистрирован аккаунт (замкнутый круг: почта на этом же домене плюс скомпрометированный регистратор — и атакующий меняет всё сразу), отсутствие 2FA.
2. Социальная инженерия против службы поддержки регистратора. Атакующий звонит или пишет в поддержку, выдаёт себя за владельца домена, просит сменить NS-записи, email на аккаунте или инициировать transfer домена к другому регистратору.

Оба сценария закрываются одними и теми же мерами — сильной аутентификацией на стороне регистратора и лимитами на то, что вообще можно изменить без ручной верификации.

Признаки, что дело именно в NS-записях, а не в обычном сбое

Отличить захват домена от рядового технического сбоя можно за несколько минут, если знать, куда смотреть.

Косвенные признаки (то, что вы замечаете первым):

• Сайт резолвится, но отдаёт не ваш контент — часто это фишинговая страница или заглушка «домен продаётся».
• Почта перестала приходить или начала отбрасываться с ошибками вида 550 relay denied — потому что MX теперь указывает не на ваш сервер.
• Браузер или почтовый клиент внезапно ругается на TLS-сертификат — потому что сертификат теперь выпущен не для того сервера, куда реально стучится клиент.
• Партнёры или клиенты пишут, что получили странное письмо «от вас» или увидели необычный сайт по знакомому адресу.

Прямые признаки — то, что подтверждает диагноз через WHOIS/RDAP и dig:

Проверьте, кто сейчас числится сервером имён для домена в реестре:

whois example.com | grep -i "name server"

или через RDAP (сейчас у большинства реестров это основной протокол, WHOIS часто отдаёт урезанный вывод):

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.nameservers'

Сравните это с тем, что реально отвечает на DNS-запросы:

dig NS example.com +short
dig NS example.com @8.8.8.8 +short
dig NS example.com @1.1.1.1 +short

Если WHOIS/RDAP показывает серверы имён, которые вы не заказывали, — это почти наверняка не сбой, а изменение делегирования в реестре, то есть кто-то зашёл в аккаунт регистратора (или убедил поддержку) и поменял NS-записи. Если же в WHOIS всё в порядке, а резолверы вроде 8.8.8.8 отдают что-то не то — ищите проблему на уровне кэша резолвера или собственного DNS-сервера, это уже другой класс инцидента.

Ещё один диагностический шаг — трассировка делегирования от корня:

dig +trace example.com

Команда пройдёт от корневых серверов через TLD-серверы (.com, .ru и так далее) до тех NS, что реально прописаны в реестре. Это самый надёжный способ увидеть именно то делегирование, которое видит весь интернет, а не то, что закэшировано у вас локально.

Важный нюанс с TTL: если атакующий сменил NS-записи только что, часть резолверов в мире ещё будет отдавать старые (корректные) значения из кэша, пока не истечёт TTL записи NS в родительской зоне (обычно от нескольких часов до 2 суток у большинства TLD). Это не значит, что атаки нет — это значит, что распространение подмены идёт волнообразно, и в ближайшие часы ситуация будет только ухудшаться.

Первые действия: что делать в первый час

Порядок здесь важнее скорости — паническая смена паролей без понимания масштаба доступа атакующего может привести к тому, что вы закроете себе диагностику, а атакующему оставите лазейку.

1. Зафиксируйте текущее состояние. Сохраните вывод whois, dig NS, dig +trace, скриншоты панели регистратора (если ещё есть доступ) и панели DNS-хостинга. Это пригодится и для восстановления, и для последующего разбора инцидента, и как доказательства для поддержки регистратора.
2. Немедленно свяжитесь с регистратором — не через email (он может быть скомпрометирован вместе с остальным), а через официальный телефон поддержки или чат в личном кабинете, если вход ещё сохранился. Сообщите: домен, дату/время обнаружения, что именно изменено (NS-записи, email на аккаунте, контакты владельца), приложите зафиксированные whois/dig-выводы.
3. Попросите немедленно заблокировать любые изменения по домену — большинство регистраторов может поставить домен на clientTransferProhibited/clientUpdateProhibited/clientDeleteProhibited вручную по звонку, даже если аккаунт скомпрометирован, — это заморозит домен до восстановления доступа и не даст перевести его к другому регистратору.
4. Проверьте email, привязанный к аккаунту регистратора. Если атакующий сменил и его — это первое, что нужно вернуть; без контроля над этим email восстановление аккаунта будет долгим (регистратор обязан проверять личность через официальные каналы, а не просто «сбросить пароль на почту»).
5. Не трогайте DNS-хостинг и NS-серверы, если они не были целью. Часто атака — именно на делегирование в реестре, а ваш реальный DNS-сервер (например, PowerDNS или Bind9) вообще не тронут: как только делегирование вернут на правильные NS, всё заработает само.

Восстановление контроля и что просить у регистратора

После того как домен заморожен от дальнейших изменений, задача — вернуть себе легитимный доступ и защитить его так, чтобы повторный захват стал практически невозможен.

Что подтвердить регистратору при восстановлении доступа:

• Данные владельца домена так, как они были указаны при регистрации — регистратор обязан свериться именно с этим, а не с тем, что видит в текущем (скомпрометированном) состоянии аккаунта.
• Историю платежей за домен, если такая привязка есть, — часто самый быстрый способ доказать легитимность.
• Доступ к альтернативному каналу связи, который вы указывали заранее (резервный email, телефон) — поэтому эти поля стоит заполнять заранее, а не постфактум.

Что включить сразу после возврата доступа:

1. Смена пароля аккаунта регистратора — новый, уникальный, не пересекающийся ни с одним другим сервисом, желательно через менеджер паролей.
2. Двухфакторная аутентификация (2FA) на аккаунте регистратора — TOTP-приложение (не SMS, если есть выбор: SMS перехватывают через подмену SIM). Общие принципы настройки 2FA для панелей управления разобраны в статье про двухфакторную аутентификацию для панелей управления — логика та же, независимо от того, панель это хостинга или личный кабинет регистратора.
3. Registry lock, если TLD и регистратор его поддерживают. Это отдельный, более жёсткий уровень защиты, чем обычный transfer-lock в аккаунте: изменения в NS-записях, контактах и статусе домена требуют ручного подтверждения через отдельный защищённый канал (обычно — звонок по заранее оговорённому протоколу с кодовыми словами или подписанным запросом), причём подтверждение идёт напрямую в реестре. Это снижает риск и от компрометации аккаунта, и от социальной инженерии против поддержки, но доступен не для всех TLD и не у всех регистраторов — часто это платная опция. Стоит уточнить отдельно, доступен ли registry lock для вашей зоны.
4. Пересмотр контактных данных на аккаунте — актуальный email (не на этом же скомпрометированном домене), актуальный телефон, включённые уведомления о любых изменениях домена.
5. Аудит всех, у кого был доступ к аккаунту — сотрудники, подрядчики, автоматизация с API-ключом регистратора. Отозвать всё лишнее, выпустить новые ключи API, если они использовались.

После восстановления: что проверить, прежде чем выдохнуть

Возврат NS-записей на правильные значения — не конец истории, а начало проверки последствий.

• Сверьте все DNS-записи целиком, не только NS. Атакующий, имея доступ к зоне (или к делегированию на свой DNS-сервер), мог добавить постоянные A/CNAME-записи на поддомены, о которых вы забыли, или TXT-записи, используемые для верификации сторонних сервисов (Google Workspace, SPF/DKIM и так далее). Сравните текущее состояние с последним известным бэкапом зоны — регулярные дампы DNS-сервера здесь окупаются именно в такие моменты.
• Проверьте SPF/DKIM/DMARC. Если почта временно шла через чужой MX, убедитесь, что записи не изменены и что не осталось подписанных писем с ключом, которого больше нет в вашем DNS.
• Перевыпустите TLS-сертификаты, если есть хоть малейшее подозрение, что атакующий успел пройти доменную валидацию у любого центра сертификации, пока управлял DNS. Проверить, не висит ли где-то валидный, но не ваш сертификат, можно через crt.sh (поиск по имени домена в логах Certificate Transparency) — это тот же принцип, что описан в статье про мониторинг сертификатов и доменов.
• Смените пароли на всём, что могло быть доступно через восстановление по почте на этом домене — если атакующий контролировал MX хотя бы несколько часов, любой сервис, где стоит «забыли пароль → письмо на ваш email на этом домене», нужно считать потенциально скомпрометированным, и начинать стоит с самых критичных: платёжные системы, облачные консоли, репозитории кода.
• Составьте таймлайн инцидента по образцу общего плана реагирования — что, когда и в каком порядке происходило, что вы предприняли и когда. Общая структура такого разбора — в статье план реагирования на инцидент: что делать при взломе. Это пригодится и для внутреннего разбора, и если понадобится объяснять ситуацию клиентам или партнёрам.

Мониторинг NS-записей: как не пропустить следующую попытку

Главная проблема захвата NS-записей — то, что жертва часто узнаёт о нём не сразу, а через жалобы пользователей или клиентов, то есть спустя часы или дни после факта. Это время можно и нужно сократить до минут.

Что стоит мониторить регулярно:

# Простой скрипт для крон-проверки NS-записей домена
#!/bin/bash
DOMAIN="example.com"
EXPECTED_NS="ns1.yourdns.example.,ns2.yourdns.example."
CURRENT_NS=$(dig NS "$DOMAIN" +short | sort | tr '\n' ',' )

if [ "$CURRENT_NS" != "$(echo "$EXPECTED_NS" | tr ',' '\n' | sort | tr '\n' ',')" ]; then
    echo "ВНИМАНИЕ: NS-записи $DOMAIN изменились: $CURRENT_NS" \
      | mail -s "ALERT: NS changed for $DOMAIN" ops@example.com
fi

Запускать такую проверку раз в 15–30 минут через cron — недорого по ресурсам и закрывает главный риск: узнать о подмене не от клиентов, а от собственного мониторинга, в первые минуты, а не через сутки.

Что дополнительно стоит держать под наблюдением:

Отдельно стоит подписаться на уведомления регистратора об изменениях — большинство крупных регистраторов присылает email при любом изменении NS, контактов или статуса домена. Если такое письмо приходит, а вы ничего не меняли — это сигнал действовать немедленно.

Если у вас несколько доменов на одном аккаунте регистратора, имеет смысл вести отдельный список ожидаемых NS-записей для каждого и проверять весь набор одним скриптом — вручную свериться по десяткам доменов при инциденте будет уже некогда.

Частые вопросы