Как сменить NS-серверы домена без простоя

Смена NS-серверов — одна из немногих операций с DNS, которая может вывести из строя весь домен: сайт, почту, API, всё сразу. Ломается редко из-за самого переключения. Ломается потому, что новая зона оказалась неполной, потому что TTL был длиной в неделю или потому что DNSSEC всё ещё указывал на старого провайдера.

Эта статья — план, которому мы следовали бы сами. В примерах используются только зарезервированные имена и документационные адреса.

Что на самом деле происходит при смене NS-серверов

NS-записи вашего домена находятся в двух местах:

У родителя (реестр зоны .com, .org, .com.tr…). Это делегирование. Его вы меняете у регистратора.
Внутри вашей собственной зоны, которую обслуживает DNS-провайдер. Они должны совпадать с делегированием.

Когда резолверу нужен www.example.com и в кэше ничего нет, он спрашивает родительскую зону, кто отвечает за домен, получает делегирование и затем обращается к одному из этих NS-серверов. Сменить NS-серверы — значит изменить делегирование у родителя.

Ничего никуда не «отправляется». Резолверы по всему миру продолжают пользоваться тем, что у них в кэше, пока оно не истечёт, потом спрашивают заново и получают новый ответ. Поэтому говорят о «распространении» (propagation), и поэтому это слово вводит в заблуждение: никакой волны, расходящейся по свету, нет, есть только кэши, истекающие в разное время.

Шаг 1. Инвентаризация старой зоны

Экспортируйте полную зону у старого провайдера. Если есть кнопка экспорта (формат BIND), воспользуйтесь ею. Если нет, выпишите каждую запись вручную. Записи, о которых забывают:

MX и TXT-записи для SPF, DKIM-селекторов (selector._domainkey) и _dmarc;
TXT-записи подтверждения для консолей поисковых систем, SaaS-инструментов и выпуска сертификатов;
CAA-записи;
SRV-записи (_sip, _autodiscover, _matrix…);
поддомены, делегированные в другое место собственными NS-записями;
wildcard-записи (*.example.com).

Публичная проверка показывает только те имена, о которых вы спрашиваете, так что экспорт она не заменит. Но как перекрёстная проверка она полезна:

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Шаг 2. Соберите новую зону и проверьте её напрямую

Создайте каждую запись у нового провайдера до того, как трогать делегирование. Затем опросите новые NS-серверы напрямую, минуя кэши, и сравните со старыми:

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Повторите для каждого типа записи и каждого имени хоста из вашей инвентаризации. Ответы должны совпадать в точности, если только вы не меняете что-то намеренно. Не поддавайтесь соблазну совместить переезд NS-серверов с переездом сервера: меняйте по одной вещи за раз, чтобы у проблемы была одна возможная причина.

Шаг 3. Заранее снизьте TTL

Важны два TTL:

TTL ваших записей у старого провайдера. Снизьте их (обычно до 300 секунд) как минимум за один старый TTL до переезда. Если старый TTL был 86400, сделайте это за сутки или раньше.
TTL делегирования у родителя. Его вы не контролируете. У многих TLD это 48 часов (172800 секунд). Это и есть настоящая длина вашего окна миграции.

Из-за второго пункта планируйте так, чтобы оба набора NS-серверов отвечали корректно как минимум два-три дня.

Шаг 4. Сначала разберитесь с DNSSEC

Если домен подписан, у родителя хранится запись DS, которая указывает на ключ старого провайдера. Если переключить NS-серверы, пока этот DS на месте, а новый провайдер подписывает другим ключом (или не подписывает вовсе), проверяющие резолверы сочтут каждый ответ недостоверным. Домен погаснет для большой доли пользователей, и снижение TTL вас не спасёт. Как устроена цепочка доверия, объяснено в статье что такое DNSSEC.

Сначала проверьте:

$ dig +short example.com DS

Если запись DS есть, выберите один из путей:

На время переезда снять подпись. Удалите DS у регистратора, дождитесь истечения TTL DS у родителя (часто 24 часа и больше), смените NS-серверы, затем включите DNSSEC у нового провайдера и опубликуйте новый DS.
Провести миграцию с несколькими подписантами, если оба провайдера её поддерживают: каждый публикует открытый ключ другого до переключения. Домен остаётся подписанным всё время, но нужно содействие обеих сторон.

Шаг 5. Переключите делегирование

У регистратора замените старые NS-серверы новым набором. Вводите их ровно так, как перечисляет новый провайдер. Некоторые реестры выполняют технические проверки и отклоняют изменение, если новые серверы не отвечают авторитетно за зону; это ещё одна причина сначала завершить шаг 2.

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

Шаг 6. Проверьте из нескольких мест

Проверьте, как это видит родитель, напрямую:

$ dig +trace example.com NS

Затем опросите несколько публичных резолверов и сравните. Какое-то время ответы будут разными. Это нормально и не означает поломки, пока обе зоны отдают одни и те же данные.

На что смотреть:

Какой набор NS возвращает каждая точка: старый или новый? Частичный набор (один старый, один новый) — не успех.
Совпадают ли ответы A, AAAA и MX между старым и новым?
По-прежнему ли HTTPS предъявляет действительный сертификат и приходит ли почта?

Осторожнее с формулировками вроде «распространено на 85 %». Ни один инструмент не может измерить каждый резолвер в интернете. Честное утверждение уже: «9 из 12 наблюдаемых точек возвращают новые NS-серверы, 2 всё ещё возвращают старые, 1 проверить не удалось».

Шаг 7. Выводите старую зону осторожно

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

План отката

Перед началом запишите имена старых NS-серверов и сохраните старую зону нетронутой. Если после переключения что-то не так:

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

Частые ошибки

Сначала переключить, а записи воссоздавать потом.
Забыть DKIM-селекторы, из-за чего почта через несколько дней начинает проваливать DMARC.
Оставить запись DS при переезде к провайдеру, который не подписывает тем же ключом.
Удалить старую зону в тот же день.
Считать один удачный запрос с собственного ноутбука доказательством того, что переезд завершён.

Проверьте в OrbitProbe

Используйте проверку DNS-записей, чтобы увидеть записи и NS-серверы, которые публичные резолверы возвращают для вашего домена прямо сейчас, и проверку WHOIS, чтобы убедиться, какие NS-серверы и состояние DNSSEC зафиксированы в реестре. В рабочем пространстве OrbitProbe можно также создать наблюдение за тем набором NS-серверов, который вы ожидаете; оно сообщает, сколько наблюдаемых точек совпадает, какие всё ещё показывают старое значение и какие проверить не удалось.