Смена DNS-записи с путём отката: снижение TTL, переключение и проверка

Цель

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

Предварительные условия

Права на запись в авторитативную зону; способ опрашивать авторитативные серверы и публичные резолверы напрямую (dig @server name type); новая цель, которая уже работает и протестирована по адресу или под временным именем.

Шаги

1. Считайте текущий TTL. RFC 1035 определяет его как временной интервал, в течение которого запись может храниться в кэше, прежде чем источник будет опрошен снова; любой кэш, хранящий запись, удерживает её после изменения ещё на срок до этого значения.
2. Снизьте TTL до нескольких минут (например, до 300 секунд) и подождите как минимум один полный старый TTL, чтобы у всех кэшей, хранивших запись с длинным TTL, она успела истечь и была заново получена уже с коротким. Пропуск этого ожидания — частая причина того, что изменение как будто «распространяется» целый день.
3. Подготовьте откат: зафиксируйте точное значение старой записи и держите старую цель работающей на всём протяжении изменения.
4. Внесите изменение. Проверьте сначала авторитативные серверы, затем публичные резолверы, затем резолвер в локальной сети.
5. Следите по логам новой цели за появлением трафика, а по логам старой — за его угасанием в течение короткого TTL. Не останавливайте старую цель, пока она не будет «тихой» дольше, чем длится TTL. RFC 8767 разрешает рекурсивному резолверу, который не может связаться с авторитативными серверами, продолжать отвечать данными с истёкшим TTL, и предлагает максимальный таймер устаревания от 1 до 3 дней; это имеет значение только если авторитативные серверы недоступны, что само по себе — довод не менять DNS во время инцидента у провайдера.
6. Когда старая цель «затихла», верните TTL к обычному значению. Откат — это то же изменение в обратную сторону, и для вступления в силу ему достаточно одного короткого TTL, поэтому TTL и остаётся низким вплоть до подтверждения.
7. Занесите оба значения записи и метки времени в календарь изменений.

Ожидаемый результат

Трафик переключается в течение минут после изменения, ни один пользователь не попадает на неработающую цель, а откат — это одно изменение записи с известной оценкой задержки в худшем случае.

Ограничения и основание проверки

Некоторые клиенты игнорируют TTL: долгоживущие соединения, кэши адресов на уровне рантайма, корпоративные прокси; им требуется перезапуск или собственное истечение срока. У негативного кэширования ещё не существовавшего имени свой TTL: RFC 2308 задаёт его как минимум из поля MINIMUM записи SOA и собственного TTL записи SOA. Процедура следует указанным RFC; никаких сроков распространения, помимо арифметики TTL, не утверждается.