После смены IP-адреса сервиса часть клиентов продолжает обращаться по старому адресу ещё долгое время. Как TTL и кэширование DNS-записей влияют на это и как минимизировать проблему при планируемой миграции?

Короткий ответ

Каждая DNS-запись имеет TTL (время жизни в секундах), в течение которого резолверы (у провайдера, на клиенте, в приложении) вправе отдавать закэшированный ответ, не обращаясь заново к авторитативному серверу; если перед миграцией TTL был большим (например, несколько часов), часть клиентов будет использовать старый IP ещё долго после смены записи, независимо от того, насколько быстро обновился сам DNS-сервер.

Как это работает подробнее

Резолверы на разных уровнях (ОС клиента, локальная сеть, публичные DNS вроде 8.8.8.8, сами приложения с собственным DNS-кэшем) независимо друг от друга кэшируют ответ на срок TTL; авторитативный сервер физически обновляет запись сразу, но не может принудительно 'протолкнуть' инвалидацию в уже существующие кэши — миграция распространяется постепенно по мере истечения TTL у каждого конкретного кэша.

Пример кода

commands.shКопировать

dig example.com +noall +answer   # смотрим текущий TTL в секундах

Что использовать на практике

• Практика. перед плановой миграцией IP заранее (за TTL до старого значения плюс запас) уменьшают TTL записи до небольшого значения (например, 60 секунд), ждут, пока старое большое значение TTL точно истечёт везде, выполняют смену IP, а через некоторое время после подтверждения успешной миграции возвращают TTL к обычному большему значению для снижения нагрузки на DNS-инфраструктуру.

Подводные камни

• Риск. Частая ошибка — поменять IP-адрес и TTL одновременно в момент миграции, ожидая мгновенного переключения всех клиентов: старые закэшированные ответы с прежним длинным TTL всё ещё будут использоваться теми, кто их получил до изменения.