Миграция зоны между DNS‑провайдерами часто откладывается «на потом»: страшно трогать NS, непонятно, как согласовать SOA и serial, где закопан TTL, и что такое «окно переключения» на практике. На самом деле «zero downtime» для DNS достижим, если заранее согласовать параметры зоны, организовать репликацию (AXFR/IXFR), и грамотно спланировать шаги с учетом кэширования на резолверах и делегирования у родительской зоны.
Когда имеет смысл мигрировать DNS‑провайдера
Причины бывают разные: рост нагрузки и потребность в anycast, недоступность текущего API, отсутствие DNSSEC/ALIAS, медленные обновления зоны, геораспределение, требования к аудитам и журналированию изменений. Независимо от мотива, цель одна — перенести зону так, чтобы клиенты и роботы не заметили переключения, а запросы к A/AAAA/MX/TXT/SRV и другим записям продолжили отвечать без перерывов.
Базовые термины: зона, SOA, NS, TTL, serial, AXFR/IXFR
Перед стартом синхронизируем терминологию:
- Зона — поддерево пространства имен, которым управляет авторитетный сервер. Граница зоны задается записями делегирования NS у родителя.
- SOA — «Start of Authority», корневая запись зоны с метаданными: владелец, контакт, параметры репликации и
serial. Именноserialдвигает AXFR/IXFR. - NS — список авторитетных серверов для зоны. Делегирование у родителя указывает на NS и, при необходимости, glue A/AAAA для них.
- TTL — время кэширования ответа резолверами. В контексте миграции критичны TTL для NS (в родительской зоне) и для записей внутри самой зоны. Подробнее о TTL — в материале как работает TTL в DNS.
- AXFR/IXFR — полная и инкрементальная передача зоны. Используются для вторичных серверов и при переезде между провайдерами.
Главная идея «zero downtime» проста: оба набора NS должны отвечать идентично в момент переключения делегирования. Это достигается синхронизацией зоны и правильными TTL.
Стратегия миграции без простоя
Рабочая схема состоит из семи этапов: аудит, снижение TTL, подготовка SOA/serial, репликация, проверки, окно переключения и наблюдение после. В некоторых случаях полезно делегировать отдельные подзоны заранее (поэтапный перенос) — это снижает риск.
Этап 1. Аудит текущей зоны
Снимите «слепок» зоны на текущем провайдере. Важно получить полный список RRset: A/AAAA, MX, TXT (SPF/DKIM/DMARC), CNAME, SRV, NS для подзон, CAA, PTR (если это обратная зона), а также проверить наличие ALIAS/ANAME на апексе. Обратите внимание на нестандартные TTL, использованные для отдельных записей, и на wildcard‑записи (*.example.com), чтобы не потерять их при экспорте/импорте.
Проверьте, поддерживает ли старый провайдер AXFR или API для выгрузки зоны. Если планируется «вторичный» сценарий, проверьте возможность настроить новый провайдер как secondary (с включенным AXFR/IXFR и TSIG).
Этап 2. Управление TTL и подготовка окна переключения
За 24–72 часа до переключения снизьте TTL на ключевых записях внутри зоны (A/AAAA для апекса и www, MX, TXT, SRV, записи для критичных API). Часто выбирают 300–600 секунд. Это сократит период, когда резолверы будут хранить старые ответы.
Помните, что TTL для NS в родительской зоне отличается от внутренних TTL и может быть 24–48 часов. На него вы прямо не влияете — поэтому планируйте окно переключения так, чтобы оба набора NS отвечали одинаково в течение как минимум двух TTL родительского NS. Это даёт уверенность, что клиенты, кэширующие старые NS, не уйдут в «параллельную реальность».
TTL нужно снижать заранее и поднимать уже после миграции. Не меняйте TTL в день переключения — резолверы увидят новое значение только после истечения текущего.
Этап 3. Подготовка зоны на новом провайдере: SOA и serial
Импортируйте зону и согласуйте SOA. Критично, чтобы поле serial было не меньше, чем у текущего мастера. На практике удобно использовать формат YYYYMMDDnn (например, 2025102601), увеличивая его при каждом изменении. Если новый провайдер сам управляет serial, убедитесь, что он стартует с большего значения — иначе вторичные не примут IXFR.
Остальные параметры SOA (refresh/retry/expire/minimum) подберите под вашу модель обновлений. Типичные значения: refresh 3600, retry 900, expire 1209600, minimum 300. Помните, что в современных реалиях minimum используется как отрицательный TTL (RFC 2308), а не как глобальный TTL для всех записей.
Этап 4. Репликация: AXFR/IXFR, Secondary DNS, hidden master
Идеальный вариант — временно сделать старого провайдера «hidden master», а новый — «secondary». Включите AXFR/IXFR, настройте фильтр по IP и TSIG для подписанных трансферов. Тогда любые изменения зоны до переключения NS будут автоматически попадать на новый провайдер.
Если AXFR недоступен, используйте экспорт/импорт и сравнение зон. Внесите freeze‑период в календарь команды: за час до окна переключения замораживаем изменения и обновляем serial на обеих сторонах, чтобы состояние было «бит‑в‑бит» одинаковым.
Этап 5. Проверки на一致ность
Проверьте, что оба набора NS отдают одинаковые ответы и одинаковые TTL. Сравните апекс, критичные имена и wildcard. Проверьте авторитетность ответов (флаг AA), поведение при NXDOMAIN и наличие SOA в дополнительной секции при отрицательном ответе (negative caching). Если используется SMTP — отдельно сверьте MX, SPF (TXT), DKIM селекторы, DMARC.
Этап 6. Окно переключения: делегирование NS у родителя
На этапе переключения вы меняете NS в родительской зоне (у регистратора домена). Если используете vanity‑NS (например, ns1.yourdomain.tld), заранее зарегистрируйте glue‑записи A/AAAA для новых NS — без этого часть резолверов не сможет найти ваши авторитетные серверы. При необходимости перенесите домен к удобному регистратору через регистрацию доменов.
Планируйте окно на середину рабочей недели и в «плечо» низкой нагрузки. После обновления NS в делегировании часть трафика будет ходить к старым NS (из‑за их кэша у резолверов), часть — к новым. Ваша задача — держать зоны идентичными до истечения двух TTL делегирования NS у родителя. Именно это даёт реальное «zero downtime».
Этап 7. Наблюдение и откат
После переключения отслеживайте долю запросов на старые и новые NS по логам. Проверьте метрики задержек ответа, процент SERVFAIL, количество NXDOMAIN, ошибки валидации DNSSEC. Держите план отката: при необходимости временно верните старые NS в делегирование, сохранив синхронизацию зоны. Как только доля запросов к старым NS упадёт до нуля и пройдет два полных TTL делегирования, можно отключать старую инфраструктуру и возвращать нормальные TTL для записей.
SOA: что влияет на «zero downtime»
SOA — сердце вашей зоны. Важное правило: serial должен монотонно возрастать. Не «откатывайте» время в формате YYYYMMDDnn при переносе, иначе вторичные перестанут принимать IXFR и могут перейти на AXFR, что увеличит окно несогласованности. Перед окном переключения принудительно увеличьте serial и убедитесь, что оба провайдера отдают одинаковое значение.
Параметры refresh, retry, expire влияют на частоту опроса мастера вторичными (актуально в сценарии hidden master). Слишком маленький refresh создаст лишнюю нагрузку, слишком большой — увеличит время расхождений при изменениях. Практика: 15–60 минут на refresh и 5–15 минут на retry — компромисс между свежестью и нагрузкой.
DNSSEC: аккуратный перенос ключей и DS
Если зона подписана, добавляется ещё один слой плана. Безопасных сценариев два:
- Pre‑publish: новый провайдер поднимает те же ключи (KSK/ZSK) и параметры подписи, вы публикуете новый DS или сохраняете текущий (если KSK общий), затем переключаете NS. Это минимизирует риск SERVFAIL.
- Временное отключение DNSSEC: снимаете DS у родителя, ждёте TTL, переключаете NS, включаете подпись и публикуете новый DS. Это проще, но на время пропадает защита валидацией.
Проверяйте цепочку доверия до корня и валидируйте ответы через резолверы с включённой проверкой (достаточно нескольких публичных и собственных). Любая рассинхронизация KSK/DS в окне переключения даст SERVFAIL вместо «мягкого» NXDOMAIN. См. также пошаговое руководство по безопасному включению DNSSEC.
Почта и внешние сервисы: MX, SPF, DKIM, CAA
Для MX критичны не только сами записи, но и A/AAAA хостов, на которые они указывают, а также обратные PTR (для отправки). Убедитесь, что SPF (TXT) не превышает лимит по числу include и запросов DNS — некоторые провайдеры делают автоматический SPF‑flattening, другие — нет. Для DKIM перенесите все селекторы без изменений. Проверьте CAA — при несовпадении можно сорвать выпуск сертификатов в день миграции. Если вы выпускаете TLS для сайта и почты, держите актуальные SSL-сертификаты.
Особые случаи: ALIAS/ANAME, CNAME на апексе, GeoDNS
Если текущий провайдер поддерживает ALIAS/ANAME для апекса, убедитесь, что новый провайдер умеет то же или спланируйте замену на A/AAAA через внешнее обновление по API. Для GeoDNS соответствие ответов «бит‑в‑бит» не обязательно, важно равенство политики (правил геораспределения) и наборов таргетов. Сравнивайте поведение с разных регионов.
Типичные ошибки
- Снижение TTL слишком поздно. Результат — долгое «эхо» старых значений у кэширующих резолверов.
- Несогласованный
serialна старом и новом провайдерах. Вторичные игнорируют изменения и остаются на старом состоянии. - Забытые glue‑записи для vanity‑NS — часть клиентов теряет доступ к авторитетным серверам.
- DNSSEC с неподтверждённым DS — массовые SERVFAIL у валидирующих резолверов.
- Разные wildcard или отсутствующие вспомогательные записи (например, селекторы DKIM).
- Отсутствие freeze‑периода — изменения, внесённые «в последний момент», теряются на одной из сторон.
Чек‑лист «zero downtime» миграции
- Снимите полную выгрузку зоны и проверьте редкие типы записей (SRV, CAA, NAPTR, ALIAS, wildcard).
- Снизьте TTL внутренних записей до 300–600 за 24–72 часа до окна.
- Поднимите зону у нового провайдера, согласуйте SOA и увеличьте
serial. - Настройте репликацию:
AXFR/IXFRсTSIGили регулярный дифф‑импорт и freeze‑период. - Сверьте ответы обоих наборов NS по критичным именам, проверьте AA и TTL.
- Подготовьте DNSSEC‑стратегию (pre‑publish или временное отключение).
- Проверьте и зарегистрируйте glue для новых NS при vanity‑схеме.
- Выберите окно переключения и оповестите заинтересованных: веб, почта, API.
- Переключите NS у родителя. Держите зоны идентичными как минимум два TTL делегирования.
- Наблюдайте метрики и логи, затем верните нормальные TTL.
Минимальный набор команд для проверки
Несколько полезных запросов для верификации. Команды приведены для привычных утилит; используйте любые аналоги. Обратите внимание на проверку авторитетности (aa), соответствия SOA/serial и NS‑ответов.
dig +nocmd example.com soa @ns1.old-dns.example +nsid +multiline
dig +nocmd example.com soa @ns1.new-dns.example +nsid +multiline
# Сравнить serial
# Обязательно убедитесь, что значения одинаковые
dig example.com NS @ns1.old-dns.example
dig example.com NS @ns1.new-dns.example
# Проверить критичные записи и TTL
dig www.example.com A @ns1.new-dns.example +ttlunits
dig www.example.com A @ns1.old-dns.example +ttlunits
# Трассировка делегирования от корня (видно, какие NS сейчас у родителя)
dig +trace example.com
# Проверка DNSSEC статуса ответа
dig example.com A +dnssec +cdflagПоэтапная миграция через субделегирование
Если риск высок, начните с переноса не всей зоны, а подзоны. Создайте NS для api.example.com и делегируйте её на новые авторитетные сервера. Так вы проверите связку SOA/serial/AXFR на меньшем объёме и отловите особенности провайдера (формат импорта, лимиты, поведение ALIAS). После успешного этапа переносите апекс.
Нюансы производительности и устойчивости
На времени ответа скажется близость anycast‑узлов нового провайдера, поддержка UDP/TCP fallback, EDNS0 и лимитов по размеру ответа. Убедитесь, что новый провайдер корректно отдаёт крупные ответы (много записей TXT/SPF) и поддерживает TCP для догрузки. Для критичных зон держите минимум два NS в разных автономных системах. Если вы держите авторитетные серверы самостоятельно, разверните их на отказоустойчивом VDS и продумайте резервирование в другой локации.
Итоги
Для «zero downtime» важно не столько «когда нажать кнопку» у регистратора, сколько подготовка: снижение TTL, согласованный SOA/serial, надёжная репликация (AXFR/IXFR или эквивалент), валидация содержимого и аккуратная работа с DNSSEC и glue. При такой дисциплине смена NS становится рутинной операцией, а не источником ночных инцидентов.
