Что делать, если изменения DNS не вступают в силу

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

Пройдите эти шаги, прежде чем считать, что всё сломано

1. Убедитесь, что изменение действительно сохранено на авторитативной стороне: запрашивайте собственные авторитативные серверы имён домена напрямую, а не обычный публичный резолвер, чтобы исключить тихо не сохранившееся изменение или то, что оно ещё не синхронизировалось внутри инфраструктуры провайдера.
2. Проверьте прежний TTL записи: если он был, скажем, 86400 секунд (24 часа), резолвер, закешировавший старый ответ за несколько минут до вашего изменения, не спросит снова вплоть до целых суток.
3. Исключите кеш DNS на уровне браузера или ОС: он находится даже ближе к вам, чем настроенный резолвер, и может хранить ответ независимо от него.
4. Убедитесь, что вы изменили именно ту запись, которую собирались: на удивление частая ошибка — случайно обновить тестовую или непроизводственную DNS-зону.
5. Проверьте из нескольких точек: то, что один резолвер показывает старый ответ, не говорит о том, распространилось ли изменение во всех остальных местах.

Менее очевидная причина: вторичный сервер имён отстаёт

В крупных DNS-конфигурациях часто есть первичный (или «master») сервер имён, где и вносятся изменения, и один или несколько вторичных («slave») серверов, периодически копирующих зону с него через передачу зоны. Если вторичный сервер ещё не получил последнюю передачу — из-за неверно настроенного расписания передачи, сетевой проблемы между первичным и вторичным серверами или просто потому, что интервал передачи ещё не истёк, — резолверы, которые обратятся именно к этому вторичному серверу, продолжат получать старый ответ, хотя сам первичный сервер полностью актуален, а кеширование по TTL у всех резолверов давно истекло. Эта причина встречается реже обычного кеширования, но её стоит исключить отдельно, когда разные авторитативные серверы имён одного домена расходятся друг с другом, а не только когда расходятся публичные резолверы.

Планирование заранее избавляет от большей части проблем

Для плановых изменений — миграции, смены провайдера, переключения — самое эффективное, что можно сделать, это понизить TTL за день-два до работ. Это стоит небольшого увеличения числа запросов, зато изменение распространится за минуты, а не за потенциально целые сутки. Установите значение, дождитесь, пока полностью пройдёт окно прежнего TTL, внесите изменение, а затем верните TTL обратно, когда убедитесь, что всё выглядит правильно.

Очистка собственного локального кеша, когда виноват именно он

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

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