Что такое TTL DNS-записи и почему изменения доходят до людей разными волнами

MAATRIX

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

Что такое TTL и где он на самом деле хранится

TTL (time to live) — это число секунд, которое стоит рядом с каждой записью в DNS-зоне и говорит: «этот ответ можно держать в кеше вот столько времени, прежде чем спрашивать заново». TTL — свойство не домена целиком, а конкретной записи: у A-записи он может быть один, у MX — другой, у NS — третий.

В зоне это выглядит примерно так:

example.com.     3600  IN  A      203.0.113.10
example.com.     3600  IN  MX     10 mail.example.com.
www.example.com. 3600  IN  CNAME  example.com.
example.com.     86400 IN  NS     ns1.example.com.

Второе поле — TTL в секундах. 3600 — это час, 86400 — сутки. Ставится TTL при создании записи: в панели вашего DNS-провайдера (Cloudflare, PowerDNS, панель регистратора) обычно есть отдельное поле или выпадающий список рядом с записью, иногда подписанный «Auto» — тогда провайдер сам подставляет разумное по его мнению значение.

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

Кто на самом деле кеширует ваш ответ

Когда пользователь открывает сайт, его запрос почти никогда не идёт напрямую к вашему авторитативному DNS-серверу. Он проходит цепочку:

• Резолвер провайдера или публичный резолвер (DNS у интернет-провайдера, 8.8.8.8, 1.1.1.1, корпоративный DNS в офисе) — основная точка кеширования, именно здесь TTL «работает» в классическом смысле.
• Локальный резолвер на устройстве — операционная система тоже держит свой маленький кеш DNS-ответов.
• Браузер — у Chrome и Firefox есть собственный DNS-кеш поверх системного, со своими правилами.
• Промежуточные прокси и корпоративные шлюзы — иногда кешируют ответы дольше, чем предписывает TTL, если так настроено администратором.

Каждый из этих узлов кеширует независимо от остальных. Подробнее о том, через сколько рук в реальности проходит один DNS-запрос, — в статье как DNS-запрос обходит полмира.

Ключевой момент: между этими кешами нет связи и нет механизма оповещения «эй, запись изменилась, сбросьте её». DNS устроен как модель pull-with-cache: никто не отправляет push-уведомление об изменении, каждый резолвер сам, по истечении своего TTL, придёт и переспросит у авторитативного сервера.

Почему изменение приходит волнами, а не разом

Вот здесь и раскрывается вся суть проблемы. Представьте тысячу резолверов по всему миру, у которых в кеше лежит ваша старая A-запись с TTL 3600 секунд. Но они запросили её не одновременно — один резолвер закешировал её пять минут назад, другой час назад, третий — только что.

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

Получается следующая картина:

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

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

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

TTL разных типов записей и разная цена ошибки

Не все записи одинаково критичны при смене TTL — цена ошибки разная:

NS-записи — особый случай: тут действует ещё и TTL, который выставлен в родительской зоне (у регистратора, на уровне зоны верхнего домена), а он вам обычно не подконтролен и часто выше, чем TTL внутри вашей собственной зоны. Поэтому смена делегирования (переход на других NS-провайдеров) закладывается с большим запасом по времени, чем просто смена A-записи.

Как заранее снизить TTL перед плановой миграцией

Главный практический вывод из всего механизма: если вы знаете дату переключения заранее, TTL можно и нужно готовить до неё, а не в момент переезда.

Логика в три шага:

1. За какое-то время до миграции снизьте TTL записи, которую будете менять. Уменьшите значение (например, до нескольких минут) в панели DNS. Само это изменение подчиняется тому же правилу волны: пока не истечёт старый TTL, часть резолверов ещё будет помнить старое (высокое) значение TTL и не спросит вас снова так быстро. Поэтому снижать TTL нужно заблаговременно — с запасом не меньше того TTL, что действовал раньше, чтобы к моменту переезда у подавляющего большинства резолверов в кеше уже лежала запись с новым, коротким TTL.

2. Дождитесь, пока пройдёт этот запас времени, и только потом переключайте IP. Когда TTL у большинства резолверов уже маленький, сама смена A-записи на новый сервер распространится значительно быстрее — резолверы будут переспрашивать чаще.

3. Держите старый сервер живым и отвечающим ещё какое-то время после переключения. Часть трафика неизбежно продолжит идти на старый IP — из-за резолверов с более долгим кешем, из-за приложений, которые где-то захардкодили IP, из-за нестандартного поведения отдельных провайдеров. Выключать старый сервер сразу после переключения DNS — частая ошибка: пользователи с ещё не обновлённым кешем получат не «слегка устаревшую» версию сайта, а недоступность вовсе. Как именно короткий запас может не спасти при недостаточно заранее сниженном TTL, разобрано в отдельном разборе: TTL 86400 превратил переезд в двухдневный.

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

Общий план такой миграции — с шагами до, во время и после переключения — по пунктам расписан в статье как составить план миграции на новый сервер.

Как проверить, что изменение уже долетело до всех

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

Проверка через конкретный резолвер и его текущий TTL:

dig example.com A @8.8.8.8
dig example.com A @1.1.1.1

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

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

Отдельно стоит проверять dig +trace example.com — это покажет ответ именно от авторитативных серверов, минуя все кеши, и подтвердит, что на самой авторитативной стороне запись уже точно правильная (то есть проблема, если она есть, — именно в чужом кешировании, а не в вашей настройке).

Классический симптом незавершённой волны — когда часть пользователей пишет, что сайт «не открывается» или «открывается старая версия», хотя у вас всё поменяно верно; разбор похожей ситуации есть в статье сайт открывается со старого сервера после миграции.

Типичные ошибки и грабли с TTL

• Снизили TTL в день переезда, а не заранее. Само снижение TTL тоже распространяется волной — по старому, ещё не обновившемуся TTL. Эффекта «мгновенно все узнали про новый короткий TTL» не будет.
• Выключили старый сервер сразу после смены записи. Часть пользователей ещё какое-то время придёт по старому IP — они получат ошибку соединения вместо доступа к чуть устаревшей, но рабочей версии.
• Поставили TTL = 0 и ждали мгновенного эффекта. TTL = 0 формально означает «не кешировать вовсе», но часть резолверов и программных стеков либо игнорирует это значение, либо применяет собственный минимальный порог кеширования. Рассчитывать на строго нулевую задержку не стоит.
• Забыли про TTL на стороне родительской зоны при смене NS. Смена делегирования зависит не только от вашего TTL внутри зоны, но и от TTL NS-записей у регистратора — это отдельный, часто более долгий процесс.
• Спутали TTL DNS-записи с TTL IP-пакета. Это два разных механизма с одинаковым названием: TTL пакета — счётчик хопов маршрутизации, который не имеет отношения к кешированию DNS-ответов.
• Не учли негативное кеширование. Если запись какое-то время после переключения ещё не существовала под новым именем или отдавала ошибку, часть резолверов может закешировать сам факт «такой записи нет» — это отдельный механизм со своим сроком жизни.

Частые вопросы