🔖 DNS TTL: почему запись поменяли, а пользователи всё еще идут на старый IP
Классическая ситуация при миграции сервиса: DNS-запись уже поменяли. На авторитативном DNS новый IP виден. А часть пользователей все равно попадает на старый сервер.
Первое желание - это сказать: "DNS не обновился." Но чаще всего DNS как раз работает правильно. Просто сработал TTL. TTL - это Time To Live, время жизни DNS-записи в кэше. Когда резолвер получил ответ, он имеет право хранить его указанное количество секунд и не спрашивать авторитативный DNS заново. Например:
app.networkadmin.ru. 3600 IN A 203.0.113.10
3600 означает, что запись можно кэшировать 3600 секунд, то есть 1 час. Если вы поменяли IP через 5 минут после того, как чей-то DNS-резолвер закэшировал старый ответ, он может продолжать отдавать старый IP до истечения TTL. И это нормально.
▪️ Где может застрять старый DNS-ответ:
• recursive DNS провайдера
• корпоративный DNS
• DNS-кэш на роутере
• локальный кэш ОС
• браузер
• приложение с собственным DNS-кэшем
• контейнер или runtime
• CDN / reverse proxy
Поэтому один пользователь уже видит новый IP, а другой - старый.
▪️ Проверка. Проверять лучше не просто через ping, а через dig. Посмотреть текущий ответ обычного резолвера:
dig app.networkadmin.ru
Спросить конкретный публичный DNS:
dig @8.8.8.8 app.networkadmin.ru
dig @1.1.1.1 app.networkadmin.ru
Спросить авторитативный DNS напрямую:
dig NS networkadmin.ru
dig @ns1.networkadmin.ru app.networkadmin.ru
Во время диагностики важно смотреть не только IP, но и оставшийся TTL:
app.networkadmin.ru. 1842 IN A 203.0.113.10
Если TTL уменьшается - это кэшированный ответ. Если на авторитативном DNS уже новый IP, а у клиента старый - значит где-то по пути еще живет старый кэш.
▪️ Как правильно готовить миграцию:
• Заранее уменьшить TTL, например до 60–300 секунд.
• Подождать старый TTL, чтобы старые кэши успели обновиться.
• Поменять DNS-запись.
• Проверить ответы с разных резолверов.
• Не выключать старый сервер сразу.
Например, если сейчас TTL был 24 часа, нельзя просто поставить TTL 60 и через минуту ждать мгновенного переключения. Сначала нужно дождаться, пока старое значение TTL доживет в кэшах.
▪️ Частая ошибка:
• Сегодня в 12:00 TTL был 86400
• Сегодня в 12:05 поставили TTL 60
• Сегодня в 12:10 поменяли IP
А пользователи все еще могут ходить на старый IP до следующего дня, потому что часть резолверов закэшировала запись еще с TTL 86400.
#dns #ttl #network
🧑💻 NetworkAdmin
Классическая ситуация при миграции сервиса: DNS-запись уже поменяли. На авторитативном DNS новый IP виден. А часть пользователей все равно попадает на старый сервер.
Первое желание - это сказать: "DNS не обновился." Но чаще всего DNS как раз работает правильно. Просто сработал TTL. TTL - это Time To Live, время жизни DNS-записи в кэше. Когда резолвер получил ответ, он имеет право хранить его указанное количество секунд и не спрашивать авторитативный DNS заново. Например:
app.networkadmin.ru. 3600 IN A 203.0.113.10
3600 означает, что запись можно кэшировать 3600 секунд, то есть 1 час. Если вы поменяли IP через 5 минут после того, как чей-то DNS-резолвер закэшировал старый ответ, он может продолжать отдавать старый IP до истечения TTL. И это нормально.
▪️ Где может застрять старый DNS-ответ:
• recursive DNS провайдера
• корпоративный DNS
• DNS-кэш на роутере
• локальный кэш ОС
• браузер
• приложение с собственным DNS-кэшем
• контейнер или runtime
• CDN / reverse proxy
Поэтому один пользователь уже видит новый IP, а другой - старый.
▪️ Проверка. Проверять лучше не просто через ping, а через dig. Посмотреть текущий ответ обычного резолвера:
dig app.networkadmin.ru
Спросить конкретный публичный DNS:
dig @8.8.8.8 app.networkadmin.ru
dig @1.1.1.1 app.networkadmin.ru
Спросить авторитативный DNS напрямую:
dig NS networkadmin.ru
dig @ns1.networkadmin.ru app.networkadmin.ru
Во время диагностики важно смотреть не только IP, но и оставшийся TTL:
app.networkadmin.ru. 1842 IN A 203.0.113.10
Если TTL уменьшается - это кэшированный ответ. Если на авторитативном DNS уже новый IP, а у клиента старый - значит где-то по пути еще живет старый кэш.
▪️ Как правильно готовить миграцию:
• Заранее уменьшить TTL, например до 60–300 секунд.
• Подождать старый TTL, чтобы старые кэши успели обновиться.
• Поменять DNS-запись.
• Проверить ответы с разных резолверов.
• Не выключать старый сервер сразу.
Например, если сейчас TTL был 24 часа, нельзя просто поставить TTL 60 и через минуту ждать мгновенного переключения. Сначала нужно дождаться, пока старое значение TTL доживет в кэшах.
▪️ Частая ошибка:
• Сегодня в 12:00 TTL был 86400
• Сегодня в 12:05 поставили TTL 60
• Сегодня в 12:10 поменяли IP
А пользователи все еще могут ходить на старый IP до следующего дня, потому что часть резолверов закэшировала запись еще с TTL 86400.
#dns #ttl #network
🧑💻 NetworkAdmin