Блокировка регистратора vs многоуровневая защита

Представьте: вы просыпаетесь, а все домены вашей компании — продакшен, стейджинг и тот, на котором живут MX-записи, — за ночь приостановлены регистратором домена. Ничего не сломал деплой, сервер не падал. Кто-то из команды trust and safety (или, что вероятнее, автоматический конвейер обработки жалоб) щёлкнул выключатель, и ваше присутствие в интернете исчезло. Это не гипотеза: на сисадминских форумах регулярно появляются истории о том, как регистраторы отключали аккаунты из-за непроверенных жалоб, двусмысленных твитов или одной помеченной картинки среди миллионов пользовательских загрузок.

Я много лет занимаюсь разбором инцидентов для инфраструктурных команд, и картина всегда одна и та же. Инженеры тщательно проектируют резервирование вычислений — multi-AZ, multi-region, runbook'и для фейловера — а единственный актив, который нельзя просто переразвернуть, то есть само доменное имя, остаётся в одном аккаунте, защищённом паролем и, может быть, SMS-кодом. В этой статье сравниваются два подхода к такому риску: классическая блокировка регистратора (выбрать надёжного регистратора, укрепить аккаунт и доверять ему) и многоуровневая защита (считать, что регистратор может вас подвести, и строить систему с учётом этого). Спойлер: нужны оба, но спасает в три часа ночи именно второй.

Почему регистратор — особенная единая точка отказа

Большинство единых точек отказа в вашем стеке находятся под вашим контролем. Primary базы данных, NAT-шлюз, брокер сообщений — их можно реплицировать, и план фейловера вы написали сами. Регистратор устроен иначе, по трём причинам. Во-первых, это зависимость control plane, которую нельзя реплицировать. Для одного домена нельзя держать двух регистраторов: у реестра ровно один зарегистрированный спонсор. Во-вторых, отказы регистратора протекают медленно. Трансфер домена в обычных условиях занимает от пяти до семи дней, а если текущий регистратор отключил ваш аккаунт, вы можете даже не получить auth code, чтобы его начать. В-третьих, отказ часто носит враждебный характер, хотя и странным образом: атакующего нет, а против вас действует сам провайдер, основываясь на жалобе, которую вы никогда не видели.

Масштаб последствий хуже, чем обычно думают. Когда регистратор приостанавливает домен, он обычно переводит NS-записи на страницу-заглушку или просто перестаёт отвечать. Это, конечно, убивает ваш сайт. Но заодно отваливается почта (MX-записи живут в DNS), SSO, если колбэки ссылаются на ваш домен, API-клиенты, status page, если он на том же домене, и — мой личный фаворит — адрес, на который вы получали бы инструкции по восстановлению. Если почта аккаунта регистратора — admin@yourdomain.com, а yourdomain.com приостановлен, вы пытаетесь доказать свою личность поддержке с адреса, которому она не доверяет. Я видел, как эта петля съедала целый рабочий день в середине инцидента.

К тому же экономические стимулы работают против вас. Когда регистратор покупает private equity — как уже случалось с несколькими крупными игроками, — сценарий предсказуем: сокращают живую поддержку, автоматизируют обработку жалоб, поднимают цены. Автоматические системы оптимизируют свои риски, а не ваши. Приостановить домен, который потом окажется невиновным, им ничего не стоит. Оставить работающим домен, который окажется нарушителем, — значит получить проблемы с реестром и плохую прессу. Угадайте, в какую сторону ошибается автоматика.

Первый подход: блокировка регистратора — укрепить единую точку

Философия блокировки гласит: регистратор — единая точка отказа, так сделайте эту точку максимально прочной. Именно такую стратегию на практике держит большинство компаний, даже если они её не формулировали. Сделанная как следует, она выглядит так:

• Выбирайте регистратора по качеству поддержки, а не по цене. Экономия в $3 в год на домен ничего не значит рядом с одним днём простоя. Нужна телефонная поддержка, именной аккаунт-менеджер для большого портфеля и компания, с которой в случае чего можно реально судиться в своей юрисдикции.
• Включите registrar lock (clientTransferProhibited) для каждого домена, а registry lock — для критичных. Registry lock требует внеполосного подтверждения, обычно звонка с парольной фразой, перед любым изменением NS-записей или трансфером. Это неудобно, и в этом весь смысл.
• Используйте двухфакторную аутентификацию на аппаратном ключе или TOTP, но никогда не SMS. Истории о том, как агенты поддержки снимали 2FA после убедительного рассказа в чате, бесчисленны; некоторые регистраторы теперь предлагают политику «никаких изменений аккаунта без аппаратного ключа». Пользуйтесь ей.
• Для аккаунта регистратора используйте отдельный ролевой адрес почты, который НЕ лежит на домене, зарегистрированном у этого же регистратора. Например, domains-admin@example.org, зарегистрированный совсем в другом месте.
• Ограничьте доступ. Два-три конкретных человека, учётные данные в корпоративном хранилище, а не общий логин в таблице.
• Документируйте всё: номер аккаунта, PIN-коды, пути эскалации в поддержке, точные документы, которыми подтверждён аккаунт. Включите это в incident runbook.

У блокировки есть реальные сильные стороны. Она предотвращает самую частую катастрофу с регистратором, которая совсем не конфискация, а угон. Социально-инженерные трансферы и захват аккаунтов годами крали дорогие домены, и registry lock в сочетании с аппаратным 2FA останавливает почти все такие случаи. Кроме того, это дёшево и не требует постоянной инженерной работы.

Но есть неприятная правда: блокировка защищает от атакующих, но не от самого регистратора. Каждый из перечисленных контролей работает на стороне регистратора. Если его автоматика отключит ваш аккаунт, registrar lock начнёт блокировать вас, PIN для поддержки лежит в системе, до которой вы не можете дотянуться, а человек, который мог бы всё переопределить, возможно, уже не существует, потому что в прошлом квартале поддержку «оптимизировали». Практики сообщают о восстановлении за шесть и более часов даже в простых случаях ложного срабатывания и о многодневных историях, если блокировка пришлась на выходные. Блокировка необходима. Но её недостаточно.

Второй подход: многоуровневая защита — исходить из того, что регистратор может вас предать

Многоуровневая философия стартует из более мрачной посылки: однажды из-за злого умысла, автоматики или ошибки регистратор снимет ваши домены, и вам нужно вернуться онлайн раньше, чем до вас дойдёт очередь поддержки. Это тот же образ мысли, что stoит за защитным инжинирингом против катастрофических сбоев: вы не предотвращаете катастрофу, вы делаете её переживаемой.

Ключевой приём — разделить слои, которые обычно связаны вместе. Маленькие компании обычно покупают домен, используют DNS регистратора, хостятся у его же хостинг-подразделения и держат почту там же. Получается четыре единые точки отказа, сложенные в одном аккаунте. Разделите их:

• Регистрация: у регистратора A, выбранного за стабильность и поддержку.
• Авторитативный DNS: у независимого DNS-провайдера B (или у двух провайдеров в конфигурации dual-primary), управляемого как код.
• Хостинг: там, где удобно для нагрузки, и никак не связанный с первыми двумя.
• Почта: выделенный провайдер, а адреса для восстановления аккаунтов у A и B живут на ещё одном домене.
• Запасной домен: заранее подготовленный резервный домен у другого регистратора, с выпущенными TLS-сертификатами и минимальной версией самых критичных сервисов, уже отвечающих на нём.

На запасном домене стоит остановиться подробнее, потому что почти никто его не делает, а это самый эффективный ход. Когда основные домены приостановлены, TTL и кеши резолверов не дают просто «переключиться на бэкап»: бэкап должен существовать, быть прогретым и резолвиться до инцидента. Резервный домен вроде example-status.net, зарегистрированный в другом месте, с вашей status page, коммуникацией по инциденту и аварийной MX-записью, превращает катастрофу, которая убивает компанию, в неприятный, но терпимый вторник.

DNS как код: слой, который все пропускают

Вот сбой, который я видел в реальных инцидентах дважды: команда возвращает домен после приостановки регистратором, включает всё обратно, а DNS оказывается неверным. Источником истины для зоны был веб-интерфейс регистратора, который во время инцидента был недоступен и в любом случае уже разошёлся с тем, что кто-либо помнил. Восстанавливать зону на 200 записей по памяти посреди простоя — особый вид мучений. Как мы уже писали, ошибки конфигурации DNS регулярно ломают продакшен даже в штатных условиях; во время инцидента с регистратором это катастрофа.

Решение скучное: управляйте DNS-зоной как кодом, в системе контроля версий, с деплоем через CI. Инструменты вроде dnscontrol или DNS-провайдеров Terraform позволяют описать зону декларативно и отправить её сразу нескольким провайдерам. Теперь состояние DNS переживает потерю control plane любого провайдера, а «переключиться на DNS-провайдера B» — это изменение в одну строку и деплой, а не героическая сессия копипасты.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

Dual-authoritative DNS недооценивают. Большинство резолверов с готовностью опрашивают все перечисленные NS-серверы, так что если один провайдер падает (а крупные DNS-провайдеры падают), резолвинг продолжает работать. Загвоздка в синхронизации двух провайдеров, и именно её DNS-as-code даёт бесплатно. Без неё dual-provider DNS становится генератором расхождений и, пожалуй, хуже одного провайдера.

Одно предостережение про TTL: команды любят поднимать TTL до 86400 «ради производительности», а потом во время инцидента выясняется, что четверть интернета кеширует их старые NS-записи целый день. Для записей, связанных с NS, и для всего, что вы можете понадобиться поменять в экстренной ситуации, держите TTL на уровне 300–900 секунд. Лишняя нагрузка на запросы ничтожна по сравнению с гибкостью.

Лицом к лицу: когда выигрывает каждый подход

Давайте прямо о компромиссах, потому что две стратегии оптимизируют разные угрозы и разные организации.

• Модель угроз: блокировка выигрывает против угона и социальной инженерии — статистически самых частых катастроф. Многоуровневая защита выигрывает против сбоев на стороне регистратора: автоматики модерации, конфискации аккаунта, банкротства или коллапса поддержки.
• Стоимость: блокировка почти ничего не стоит — плата за registry lock, аппаратный ключ, дисциплина. Многоуровневая защита стоит счетов второго провайдера, запасного домена, CI-инфраструктуры и постоянного внимания к тому, чтобы не было расхождений.
• Время восстановления: при конфискации команды, полагающиеся только на блокировку, зависят от очереди поддержки (часы или дни — по всем историям, которые я слышал). Команды с прогретым запасным доменом возвращаются за минуты или часы.
• Операционная нагрузка: блокировка настраивается один раз и забывается. Многоуровневая защита гниёт без поддержки — непроверенный запасной домен с просроченным сертификатом это театр безопасности.
• Соответствие организации: стартап из пяти человек с одним SaaS-продуктом должен делать полную блокировку плюс два самых дешёвых слоя: внешний DNS как код и почту восстановления вне основного домена. Компании, у которой выручка умирает вместе с доменом, нужен полный многоуровневый стек.

Блокировка защищает домены от атакующих. Многоуровневая защита защищает бизнес от регистратора. Вы уязвимы для обоих, поэтому нужны оба.

Runbook восстановления, который никто не пишет, пока не стало слишком поздно

Какую бы позицию вы ни выбрали, напишите runbook на случай конфискации прямо сейчас. Инциденты, которые я видел проходящими хорошо, все его имели; катастрофы возникали там, где импровизировали. Ваш документ должен описывать по порядку: подтвердить масштаб (один домен или весь аккаунт — проверьте статусы whois вроде clientHold или serverHold), открыть тикет в поддержке с задокументированными идентификаторами аккаунта, активировать запасной домен и обновить коммуникацию по статусу, уведомить клиентов через каналы, которые не зависят от мёртвого домена, и параллельно запустить процесс трансфера наружу — не ждите разрешения ситуации, чтобы решить, что вы уходите.

Отрепетируйте и скучные части. Сможете ли вы войти в регистратора с чистого устройства, с аппаратным ключом, без менеджера паролей, который живёт за SSO на приостановленном домене? Лежит ли парольная фраза registry lock там, где её найдёт дежурный? Команды тестируют фейловер базы данных каждый квартал, а восстановление регистратора — никогда. Учитывая, что отказ регистратора отключает SSO, которым вы пользуетесь для доступа ко всему остальному, приоритеты здесь перевёрнуты.

Моя рекомендация

Сделайте блокировку полностью — это работа на полдня, и она останавливает самую вероятную атаку. Затем внедрите ровно три элемента многоуровневой защиты, в таком порядке: вынесите авторитативный DNS от регистратора и управляйте им как кодом; переведите адрес восстановления аккаунта регистратора на домен у другого регистратора; поднимите прогретый запасной домен с сертификатами, status page и аварийной MX-записью. Эти три пункта закрывают доминирующие сценарии отказа за несколько сотен долларов в год. Полную архитектуру с двумя регистраторами и двумя DNS оставьте для организаций, которые могут назвать, во что обходится один день полной потери доменов. Если эта сумма содержит шесть нулей, вы уже знаете, что делать.

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