Zero downtime: как безопасно менять DNS и SSL без простоя сайта

В реальных проектах DNS и SSL почти никогда не меняются по отдельности. Обычно это часть более крупного события: перенос сайта на новый сервер или VDS, внедрение CDN, перевод на HTTPS, смена балансировщика. И каждый такой шаг чреват простоем, если неправильно спланировать работу с DNS‑записями и сертификатами.

В этой статье разберем практический сценарий: как комбинировать изменения DNS и SSL так, чтобы получить максимально близкий к zero downtime результат. Материал ориентирован на админов, DevOps и тех, кто отвечает за прод.

Базовая модель: что происходит при смене DNS и SSL

Для начала зафиксируем, какие компоненты участвуют в «танце» DNS+SSL:

• зона DNS с записями A/AAAA, CNAME, иногда CAA;
• клиентский резолвер и кэширующие рекурсивные DNS (провайдеры, корпоративные, публичные DNS);
• сервер или несколько серверов, где крутится веб‑приложение;
• TLS‑терминатор (веб‑сервер, обратный прокси, балансировщик или CDN);
• SSL‑сертификат (обычно X.509, выданный CA, либо Let's Encrypt/ACME);
• браузер или иной клиент, который проверяет цепочку сертификатов, имя хоста и, возможно, HSTS.

При изменении DNS мы фактически меняем путь, по которому запросы клиента доходят до TLS‑терминатора. При изменении SSL мы меняем сам TLS‑терминатор (ключи/сертификат, настройки протокола).

Главный принцип zero downtime — не совмещать в один шаг смену маршрута (DNS) и замену сертификата или TLS‑терминатора. Все нужно разбивать на фазы, которые можно откатить.

Ограничения DNS: TTL, кэш, медленные провайдеры

Первая причина, почему zero downtime на DNS‑уровне — это «почти zero», а не математический ноль, — кэш.

TTL и реальный мир

TTL определяет, сколько кэширующий резолвер может хранить запись, не обращаясь к авторитетному DNS. Но на практике:

• часть провайдеров игнорирует снижение TTL (особенно из большого на маленький);
• часть клиентов использует собственный кэш (браузер, ОС);
• мобильные сети иногда ведут себя особенно агрессивно.

Поэтому при планировании:

• снижайте TTL минимум за 24 часа до миграции, а лучше за 48;
• не рассчитывайте на меньше 300 секунд как «гарантированное время переключения» — это оптимистичная оценка;
• допускайте, что часть трафика еще какое‑то время пойдет на старый IP.

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

Типовые сценарии, где завязаны DNS и SSL

Рассмотрим типовые кейсы, где нужны скоординированные изменения DNS и SSL:

• перенос сайта с одного сервера или хостинга на другой с сохранением домена;
• внедрение обратного прокси или балансировщика (Nginx/HAProxy/Caddy) между клиентом и бэкендом;
• переезд на CDN или специализированный HTTPS‑фронт;
• переезд между сертификатами (от одного CA к другому, DV → EV, RSA → ECDSA, wildcard → SAN) с изменением инфраструктуры;
• переезд панели или API на новый поддомен или новый TLS‑терминатор.

Во всех этих случаях рецепт похож: подготовить новый endpoint, поднять там SSL, протестировать, а только потом аккуратно перетаскивать DNS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Пошаговый план zero downtime миграции DNS+SSL

Ниже — обобщенный сценарий, который можно адаптировать под разные стеки. Предположим, у нас есть прод на одном сервере, и мы переезжаем на новый, меняя и DNS, и SSL.

Шаг 1. Аудит текущих DNS и SSL

Перед любыми изменениями зафиксируйте текущее состояние:

• существующие записи A/AAAA, CNAME, MX, TXT, CAA для домена и ключевых поддоменов;
• фактические TTL этих записей;
• используется ли DNSSEC (и где хранятся ключи);
• какой сертификат сейчас на фронте: имена (CN/SAN), тип (single/SAN/wildcard), алгоритм (RSA/ECDSA), срок действия;
• включен ли HSTS и, если да, какой max-age, есть ли флаги includeSubDomains и preload.

Аудит поможет понять, нет ли ограничений, которые мешают миграции, например:

• жесткий HSTS с большим max-age — исключает возвращение на HTTP;
• CAA ограничивает, какие CA могут выпускать сертификаты для домена;
• DNSSEC — значит, нельзя просто «переехать» зоной, не думая о ключах и DS в родительской зоне.

Шаг 2. Подготовка нового сервера и SSL без смены DNS

На новом сервере поднимаем окружение так, словно он уже в проде, но пока без смены DNS:

• настраиваем веб‑сервер или прокси и приложение;
• генерируем и устанавливаем SSL‑сертификат, который покрывает нужные домены;
• настраиваем редиректы HTTP→HTTPS и базовые security‑заголовки;
• гасим все тестовые и дефолтные виртуальные хосты.

Ключевой момент: сертификат должен подходить под то же доменное имя, которым уже пользуются пользователи, даже если DNS пока не смотрит на новый IP. Для тестирования используем:

• /etc/hosts (локально подменяем резолвинг домена на новый IP);
• или временный технический домен или поддомен, заранее включенный в SAN сертификата (если возможно).

Так можно полностью обкатать новый фронт, не рискуя продом.

Шаг 3. Снижаем TTL и ждем

Когда новый сервер и SSL готовы и протестированы локально, переходим к DNS:

• уменьшаем TTL для критичных записей до разумного минимума (обычно 300–600 секунд);
• особое внимание записям для веба (A/AAAA, иногда CNAME);
• фиксируем время изменения и ждем как минимум один полный старый TTL (а лучше два).

Это обезопасит нас от длительного «залипания» трафика на старом IP в момент фактического переключения.

Шаг 4. Выравнивание данных и стратегии трафика

Пока TTL уменьшается и кэши обновляются, нужно решить, как мы будем обращаться с данными и сессиями во время миграции:

• если БД общая (например, внешний кластер), нужно только убедиться, что оба фронта (старый и новый) корректно на нее работают;
• если БД переносится — продумать репликацию или временный режим read‑only;
• если используется файловое хранилище (загрузки, аватары), решить, как синхронизировать (rsync, NFS, объектное хранилище);
• если используются sticky‑сессии, решить, где хранится сессия (Redis/Memcached/БД) и будет ли к ней доступ с обоих фронтов.

Zero downtime невозможен, если часть пользователей пишет в «старую» базу или хранилище, а часть — уже в новую, и эти данные никак не синхронизируются.

Шаг 5. Фактическое переключение DNS

Далее — сам момент истины. В идеале:

• в удобное время (низкая нагрузка, но не глубокая ночь, чтобы команда была на связи);
• меняем запись A/AAAA (или CNAME) на авторитетном DNS;
• сохраняем низкий TTL хотя бы еще на несколько часов после миграции;
• ведем параллельный мониторинг: логи старого и нового фронтов, ответы HTTP, ошибки TLS.

В этот момент пройдет несколько волн трафика:

1. клиенты со «старыми» кэшами DNS продолжат ходить на старый IP;
2. часть клиентов быстро переключится на новый IP после экспирации TTL кэша у резолвера;
3. новые клиенты почти сразу попадут на новый IP.

Если старый сервер продолжает работать и видит те же данные (общая БД, общие сессии, синхронизированный storage), пользователи не заметят миграцию.

Шаг 6. Варианты отката

Zero downtime миграция всегда должна включать понятный rollback‑план:

• если с новым фронтом что‑то пошло не так — меняем запись обратно на старый IP (с тем же TTL);
• сохраняем низкий TTL, чтобы смена туда‑обратно отыграла относительно быстро;
• следим за синхронизацией данных, чтобы на время отката не потерять операции с новых клиентов.

Хороший тон — заранее протестировать rollback в staging‑окружении: изменить запись на «новый» IP, посмотреть, как реагируют клиенты и мониторинг, а затем вернуть обратно.

Специфика SSL при миграции: сертификаты, CAA, HSTS

Теперь углубимся в SSL‑часть. Здесь много мелких нюансов, из‑за которых миграция может сломаться именно на TLS‑уровне, хотя DNS уже отыграл правильно.

Сертификат для двух площадок одновременно

Оптимальная стратегия для zero downtime — поддерживать валидный сертификат на обоих фронтах (старом и новом) одновременно. Варианты:

• один и тот же wildcard или SAN‑сертификат установлен на двух серверах;
• два разных, но эквивалентных сертификата (тот же CN и SAN, другая ключевая пара или CA);
• единый фронтовый балансировщик или прокси, который держит SSL, а бэкенды общаются по HTTP или HTTPS без участия клиентов.

Главное, чтобы в любой момент времени клиент, обратившись по доменному имени, получил корректный сертификат, соответствующий этому имени, и валидную цепочку доверия. При необходимости можно заранее приобрести коммерческие SSL-сертификаты с нужными типами SAN или wildcard.

Проверяем CAA перед выпуском или переездом

Записи CAA часто забывают, пока однажды новый CA не откажет в выпуске сертификата. Перед миграцией:

• проверьте, есть ли CAA в зоне для домена и/или родительских доменов;
• убедитесь, что выбранный вами CA разрешен правилами CAA;
• если нужно, внесите изменения заранее, с учетом TTL и кэша.

Это особенно актуально, если вы переходите, например, с одного коммерческого CA на другой или с одного ACME‑клиента на другой.

HSTS и его влияние на миграцию

HSTS (Strict-Transport-Security) делает жизнь безопаснее, но усложняет миграции. Клиент, получивший HSTS для домена, больше не ходит по HTTP, даже если вы потом захотите на время отключить HTTPS или сменить домен.

При миграции важно:

• сохранять корректную и непротиворечивую SSL‑конфигурацию на обоих фронтах;
• не ронять сертификат на старом фронте до тех пор, пока не убедитесь, что трафик туда больше не идет;
• аккуратно обращаться с флагами includeSubDomains и preload — ошибки тут сложнее лечатся.

Если домен уже в HSTS Preload List, откаты и эксперименты с HTTP становятся практически невозможны. В таких случаях миграции нужно планировать особенно тщательно.

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

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

Подробнее

ACME/Let's Encrypt и DNS: HTTP‑01 vs DNS‑01

Многие проекты используют ACME (Let's Encrypt и аналоги) для автоматизации SSL. Тут важен тип challenge и его связь с DNS.

HTTP‑01: зависимость от маршрута трафика

Challenge HTTP‑01 требует, чтобы CA мог достучаться до домена по HTTP и получить токен. При миграции:

• если вы меняете IP или фронтовый сервер, убедитесь, что challenge будет обслуживаться на новом фронте;
• если раньше challenge обрабатывал старый сервер, а теперь за HTTP отвечает новый прокси, нужно перенести или проксировать спец‑путь /.well-known/acme-challenge/;
• на время миграции лучше отключить автоматическое удаление старых сертификатов до полной стабилизации трафика.

Иначе можно получить ситуацию, когда часть трафика уже на новом сервере, старый больше не обслуживает challenge, автоматическое продление ломается, сертификат истекает во время «снежного кома» изменений.

DNS‑01: мощный, но чувствительный к DNS‑инфраструктуре

DNS‑01 challenge завязан на возможность создавать временные TXT‑записи в зоне. Для zero downtime этот способ часто безопаснее, поскольку не зависит от того, куда сейчас указывает запись A домена.

Но у него есть свои нюансы:

• нужна автоматизация управления зоной DNS (API регистратуры или провайдера, либо собственный DNS‑сервер с API);
• нужно учитывать TTL TXT‑записей и возможный кэш у резолверов CA;
• при переезде зоны к другому DNS‑провайдеру нужно заранее перенести и логику ACME‑клиента.

Если вы делаете частые zero downtime смены инфраструктуры, DNS‑01 с хорошо настроенной автоматизацией обычно дает больше контроля.

Zero downtime в сложных сценариях: балансировщики, CDN, multi‑region

Есть сценарии, где одного «переноса сайта на новый IP» мало. Например, вы вводите:

• балансировщик перед несколькими бэкендами;
• CDN, которая терминирует TLS и кеширует контент;
• multi‑region или active‑active схему с географической балансировкой (GeoDNS/Anycast).

Там zero downtime требует дополнительной логики.

Миграция на балансировщик или обратный прокси

Если раньше клиенты ходили напрямую на бэкенд, а теперь их встречает Nginx или HAProxy:

• сначала поднимаем балансировщик на новом IP (или даже на старом IP, если есть доступ к сети);
• настраиваем на нем SSL, включая SNI, OCSP Stapling, приемлемый набор протоколов и шифров;
• подключаем старый бэкенд как upstream, проверяем полную функциональность;
• только потом переключаем DNS на новый фронт, который в свою очередь стучится к старому бэкенду.

Так можно отделить миграцию TLS или прокси‑уровня от миграции приложений и данных.

CDN и изменения DNS

При внедрении CDN меняется схема маршрута: домен теперь указывает на CDN, а CDN — на origin. При этом SSL может быть:

• полностью на стороне CDN (сертификат на CDN, связь с origin по HTTP или HTTPS);
• сквозной (TLS‑терминация и на CDN, и на origin).

Чтобы не получить даунтайм:

• выдайте или подготовьте сертификаты на CDN заранее;
• настройте origin‑сервер так, чтобы он корректно обрабатывал запросы от CDN (заголовки X-Forwarded-For, Host, X-Forwarded-Proto и т. д.);
• сделайте тестовый поддомен, который уже идет через CDN, и отладьте все на нем;
• после чего переключайте основной домен на CDN, когда будете уверены в стабильности.

Подробно про работу с кешированием и версионированием статики через CDN можно почитать в материале о стратегии кэш‑версий для CDN и объектного хранилища.

Проверка и мониторинг: как понять, что миграция прошла успешно

Zero downtime невозможен без внятного мониторинга и проверок «по факту».

Проверяем DNS

После изменения DNS следует контролировать:

• ответы авторитетных серверов для зоны;
• ответы популярных публичных резолверов из разных регионов;
• соответствие IP и TTL ожидаемым значениям;
• наличие и корректность CAA, TXT и других служебных записей.

Особо полезно прогнать тесты с нескольких хостов и регионов и разных сетей (мобильная, офисная, домашние провайдеры).

Проверяем SSL

Для TLS‑части нужно убедиться в нескольких вещах:

• сертификат корректен по доменному имени, сроку действия и цепочке;
• поддерживаются необходимые версии протоколов (обычно TLS 1.2 и 1.3);
• ключи и сертификаты совпадают на всех релевантных фронтах;
• OCSP Stapling работает, если он был включен;
• HSTS и другие security‑заголовки соответствуют политике проекта.

Хорошая практика — добавить synthetic‑чеки в систему мониторинга: периодически ходить на сайт, проверять TLS‑рукопожатие и содержимое страницы, а не только наличие открытого порта 443.

Практические советы и анти‑паттерны

Соберем несколько практических правил, которые снижают риск простоя при любых миграциях DNS+SSL:

• никогда не вносите одновременно крупные DNS‑изменения и большие изменения конфигурации приложения;
• мигрируйте маленькими шагами: сначала новый фронт, потом DNS, потом уже оптимизации и чистка старых конфигов;
• всегда проверяйте CAA, HSTS и сроки действия текущих сертификатов заранее;
• перед сменой DNS убедитесь, что новый фронт доступен по HTTPS с корректным сертификатом и правильными ответами приложения;
• держите план отката, где описано, какие записи вернуть и какие сервисы остановить или запустить;
• не повышайте TTL сразу после миграции — оставьте небольшой, пока не убедитесь, что все стабильно;
• документируйте каждое изменение в зоне DNS и в SSL‑конфигурации, особенно если используется несколько параллельных фронтов.

Анти‑паттерны, которые почти гарантируют проблемы:

• «быстрый фикс вечером» — незапланированная миграция в одиночку, без мониторинга и плана отката;
• отключение старого сервера сразу после смены DNS, без периода наблюдения;
• установка нового сертификата только на новый фронт, когда часть трафика еще идет на старый;
• одновременное включение жесткого HSTS и миграция инфраструктуры;
• игнорирование CAA и DNSSEC при смене DNS‑провайдера.

Итоги

Настоящий zero downtime при работе с DNS и SSL — это не магия и не «секретные настройки», а аккуратное планирование и разделение изменений на небольшие, управляемые шаги.

Ключевые принципы:

• готовим новый фронт и SSL заранее, тестируем его вне боевого DNS;
• понижаем TTL и даем кэшу обновиться до начала переключения;
• обеспечиваем одновременную работоспособность старого и нового фронта в переходный период;
• держим под рукой понятный rollback‑план и включаем мониторинг на каждом этапе;
• учитываем ограничения HSTS, CAA, DNSSEC и автоматизации ACME.

Если относиться к изменениям DNS и SSL так же серьезно, как к релизу критичных фич в коде, zero downtime перестанет быть маркетинговым лозунгом и станет реальной практикой вашей инфраструктуры. А подобрать подходящий виртуальный хостинг или VDS под такую схему можно уже с учетом всех этих требований.