TTL 30 или 300: какой выбрать для быстрого фейловера

Вы подняли резерв, переписали A-запись на новый IP — а клиенты ещё полчаса идут на упавший сервер. Знакомо? Почти всегда виновата одна маленькая цифра в DNS-зоне: TTL. Именно она решает, как быстро мир узнает о вашем переключении. Разбираемся, какой TTL выбрать, чтобы фейловер был быстрым, а нагрузка на DNS — адекватной.

Что такое TTL и кто его реально соблюдает

TTL (time to live) — время в секундах, в течение которого DNS-запись может лежать в кэше резолвера. Пока TTL не истёк, резолвер не идёт к авторитативному серверу за свежим ответом, а отдаёт закэшированное. TTL 300 означает: «этот ответ можно помнить пять минут».

Ключевой момент: TTL — не команда, а рекомендация. Записывает её владелец зоны, а исполняют тысячи чужих машин: публичные резолверы вроде 8.8.8.8 и 1.1.1.1, кэширующие серверы провайдеров, корпоративные форвардеры, DNS на роутерах. Большинство ведут себя честно. Но не все — об этом ниже.

Как резолверы кэшируют

Цепочка стандартная: браузер спрашивает системный резолвер, тот — рекурсор провайдера или публичный DNS, а рекурсор один раз ходит к авторитативному серверу вашей зоны и кэширует ответ на весь TTL. Все последующие клиенты этого рекурсора получают ответ из кэша — мгновенно и бесплатно для вас.

Отсюда следствие: после смены записи старый IP продолжает жить в кэшах ещё до одного полного TTL. При TTL 3600 часть пользователей увидит новый адрес через минуту, а часть — через час. «Хвост» неравномерен: всё зависит от того, кто и когда резолвил запись в последний раз перед переключением.

Компромисс: скорость переключения против нагрузки

Чем ниже TTL, тем чаще резолверы ходят к авторитативному серверу. TTL 30 вместо 300 — примерно вдесятеро больше запросов к DNS. Для небольшой зоны это копейки, но нюансы есть:

• у платных DNS-хостингов запросы тарифицируются — на большом трафике разница ощутима;
• низкий TTL чуть увеличивает время первого ответа: лишние 20–50 мс на резолв при промахе кэша;
• частые запросы означают больше внешней зависимости: если ваш DNS-провайдер тормозит, это заметят чаще.

Обратная сторона медали: высокий TTL — это многочасовой «хвост» при любом переключении. Переезд на другой IP, аварийный фейловер, даже банальная правка записи превращаются в часы ожидания.

TTL — это время, за которое мир забывает вашу старую запись. Выбирать его нужно заранее, а не в момент пожара.

Почему failover-записям ставят 30–60 секунд

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

При TTL 30 худший случай — полминуты устаревшего кэша. При TTL 300 — пять минут. При TTL 3600 — час. Для интернет-магазина в разгар распродажи разница между «полминуты» и «часом» — это выручка, возвраты и нервы поддержки.

Отсюда рабочая практика: боевые A/AAAA-записи, которые могут переключаться (сайт, API, приём платежей), держат на TTL 30–60. Всё остальное — MX, TXT, поддомены мониторинга, статика — спокойно живёт на 300–3600 и выше. Нагрузку дают именно «горячие» записи, а их в зоне единицы.

«Плохие» резолверы и клэмпинг TTL

Теперь о неприятном. Часть провайдеров и мобильных операторов принудительно завышает TTL: их резолверы «клэмпят» слишком низкие значения — например, всё ниже 300 превращается в 300, а то и в 900. Мотивация проста: меньше запросов наружу — меньше нагрузка на их инфраструктуру.

Как с этим жить:

• Примириться с «хвостом». Основная масса клиентов переключится за ваш TTL, но процент пользователей с клэмпящими резолверами задержится. Планируйте фейловер так, чтобы старый IP ещё 10–15 минут отдавал хотя бы заглушку или редирект.
• Не уходить в TTL 5. Смысла почти нет: клэмпинг съест весь выигрыш, а нагрузка вырастет. Практический минимум — 30 секунд.
• Гасить трафик на уровне приложения. Если старый сервер ещё жив (переключаетесь планово), пусть он редиректит или проксирует на новый — тогда чужой кэш не страшен.

Практика: какие TTL ставить

• боевая A-запись сайта и API: TTL 30, если за ней стоит фейловер; TTL 300, если переключения не предвидится;
• резервные записи (например, reserve.example.com): 60–300;
• MX, TXT, SPF, DKIM: 3600 и выше — их не переключают в пожарном порядке;
• статика и CDN-поддомены: 300–3600.

И главное правило плановых работ: за сутки до переезда снизьте TTL до 30–60, после переезда верните обратно. Старый админский трюк, который почему-то стабильно забывают именно в день миграции.

Мини-чеклист настройки

1. Узнайте текущий TTL боевой записи: dig example.com — смотрите второе число в ответе.
2. Если запись участвует в фейловере — поставьте 30–60 секунд.
3. Проверьте реальный TTL у разных резолверов: dig @8.8.8.8 example.com, dig @1.1.1.1 example.com и через резолвер вашего провайдера. Значения разошлись — у части клиентов будет «хвост».
4. Перед плановым переездом снизьте TTL заранее — минимум за один старый TTL до начала работ.
5. Держите старый IP живым ещё 15–30 минут после переключения.
6. Автоматизируйте смену записи: вручную в три часа ночи вы будете делать это медленно и с опечатками. Мы в baser переключаем DNS автоматически при падении зоны — сама запись уходит за секунды, видимость для всех клиентов определяется TTL.

TTL — дешёвая страховка: настраивается один раз за пять минут, а экономит часы простоя.