Failover по DNS срабатывает за 5 минут вместо 30 секунд: почему обещания не сбываются

MAATRIX

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

TTL — это верхняя граница кеширования, а не гарантия скорости

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

Разница между «TTL как гарантия» и «TTL как потолок» — это ровно та пропасть, в которую падают ожидания «переключимся за 30 секунд». Сама механика резолвинга — цепочка от вашего устройства через локальный резолвер до авторитативного сервера — подробно разобрана в статье как DNS-запрос обходит полмира: там же видно, сколько разных точек кеширования встречается на этом пути, и на каждой TTL интерпретируется независимо.

Практическая проверка, что реально происходит с конкретной записью прямо сейчас, — это dig с явным указанием резолвера:

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @8.8.8.8
dig +noall +answer example.com @ns1.your-provider.net

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

Резолверы и мобильные операторы, которые кешируют дольше, чем вы просили

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

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

Проверить это для своего домена можно эмпирически — через сервисы распределённых DNS-замеров (whatsmydns.net, dnschecker.org) сразу после смены записи: часть точек по миру уже отдаёт новый IP, часть — ещё старый, и отставание не одинаковое и не предсказуемое по географии.

Кеш поверх кеша: браузер, приложение, ОС

Даже если каждый резолвер на пути идеально соблюдает TTL, до конечного пользователя всё равно может дойти устаревший ответ — потому что резолвинг системы не единственный уровень кеширования. У современных браузеров есть собственный DNS-кеш поверх системного: Chrome, например, кеширует резолвинг внутри процесса и не обязан идти к ОС за каждым запросом, пока не истечёт его внутренний таймер, который не обязан совпадать с TTL записи. У мобильных приложений то же самое — многие HTTP-клиенты и SDK держат собственный пул соединений и резолвинг с внутренним TTL или вообще без учёта DNS TTL как такового, ориентируясь на время жизни самого соединения.

Добавьте сюда операционную систему: systemd-resolved на Linux, кеш DNS-клиента Windows, кеш macOS — у каждого своя логика, и в некоторых конфигурациях запись не выкидывается мгновенно по истечении TTL, а обновляется при следующем обращении с задержкой. Уже открытые TCP-соединения — отдельная история: если пользователь в момент отказа сервера уже держит открытое соединение (keep-alive, веб-сокет), смена DNS-записи на него никак не повлияет, пока оно не закроется само — приложению придётся упасть с ошибкой и переподключиться, чтобы вообще пойти за новым резолвингом.

Итог: даже идеальное распространение записи на уровне DNS-инфраструктуры не гарантирует, что конкретный браузер обратится за новым резолвингом раньше, чем захочет сам.

Обнаружение проблемы: health check съедает время до переключения

Здесь начинается часть, которую часто вообще забывают посчитать при оценке «времени failover». Прежде чем DNS-запись поменяется, систему мониторинга ещё нужно убедить, что сервер действительно упал, а не просто на секунду задержал ответ. Типичная схема — health check раз в N секунд, и сервер признаётся мёртвым только после M подряд неудачных проверок. Это сделано намеренно: без такого порога любой единичный сетевой затык или всплеск нагрузки будет восприниматься как полный отказ, и система начнёт дёргать переключения туда-сюда — так называемый флаппинг, который вреднее, чем чуть более медленное, но стабильное решение.

Посчитайте это время явно для своей конфигурации: если health check идёт раз в 10 секунд и нужно 3 подряд неудачные проверки, чтобы признать бэкенд мёртвым, — это уже минимум 20-30 секунд только на обнаружение, ещё до того, как кто-либо начнёт менять DNS-запись. Уменьшить интервал и порог можно, но за это приходится платить ложными срабатываниями: агрессивный health check на нестабильном, но живом канале начнёт периодически объявлять здоровый сервер мёртвым. Тонкости того, почему «зелёный» health check вообще не гарантирует реальную доступность сервиса для пользователя, подробно разобраны в статье health-чек зелёный, пользователи жалуются — время на обнаружение и время на переключение записи складываются, а не поглощают друг друга.

К моменту, когда система приняла решение поменять DNS-запись, от начала фактического отказа сервера уже прошло время health-check-цикла — и это время нужно прибавлять к TTL, а не заменять им.

Распространение записи: не мгновенно и не одновременно для всех

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

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

Отдельно стоит TTL записи NS (делегирование зоны) — если кеш держит не саму A-запись, а промежуточное звено делегирования с более длинным TTL, задержка может оказаться больше, чем видно из TTL конечной записи. Для обычного failover-сценария (меняется A- или CNAME-запись) это редкость, но стоит иметь в виду при диагностике аномально долгого переключения.

Честная арифметика: сколько на самом деле займёт DNS failover

Если сложить все перечисленные слои задержки, картина получается заметно честнее, чем «TTL — это и есть время переключения»:

Цифры в таблице — не измеренные значения конкретного окружения, а порядок величин, чтобы показать складывающийся эффект; для вашего домена они будут своими, и единственный способ узнать их — измерить на практике через распределённые DNS-чекеры и синтетический мониторинг с разных точек. Но общий вывод устойчив: если health check честно даёт минимум 20-30 секунд на обнаружение, а TTL записи даже 30-60 секунд, реалистичное окно, за которое основная масса пользователей увидит переключение, обычно измеряется единицами минут, а не секундами — и это при аккуратной, не разгонянной до абсурда настройке. Пять минут вместо тридцати секунд — не худший случай, а типичный случай для честно настроенного DNS failover.

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

Что делать, если нужна секунда, а не минута

Если требования к скорости реакции жёстче, чем DNS-механика в принципе способна дать, есть несколько рабочих направлений — и все они означают отказ от идеи «переключать доступность через смену DNS-ответа» как основного механизма.

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

Балансировщик перед несколькими бэкендами. Вместо переключения DNS-записи между целыми серверами можно держать один стабильный IP, за которым стоит балансировщик (nginx, HAProxy или аналог), опрашивающий бэкенды собственными health check и выводящий мёртвый узел из ротации за секунды — клиент вообще не видит смены IP, и вся цепочка DNS-задержек из этой статьи просто не участвует. У схемы свои узкие места: сам балансировщик становится точкой отказа, если не задублирован, а состояние на бэкендах должно быть общим или не зависеть от конкретного узла. Как поднять такую схему на практике — в статье как установить и настроить балансировку нагрузки на VPS.

Честная коммуникация ожиданий. Если DNS-failover остаётся основным механизмом переключения — не обещайте в SLA время реакции, которое противоречит реальной механике DNS. Формулировка «переключение в течение TTL» вводит в заблуждение и вас, и клиентов: честнее заранее заложить реалистичное окно в несколько минут, объяснить его составляющими (обнаружение + TTL + неконтролируемое поведение части резолверов), и там, где это критично, предложить более быстрый механизм отдельно, а не маскировать ограничение DNS красивой цифрой из конфига.

На практике многие проекты комбинируют подходы: балансировщик или anycast — для быстрой реакции внутри инфраструктуры, DNS-переключение — как более медленный, но простой запасной уровень для полного отказа дата-центра или планового переезда, где счёт и так идёт не на секунды.

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