xlxa5

TTL 300 не спасает: кеш провайдера и старый A-адрес

5 сентября 2026DNSинцидент6 минут чтения

Сервис переезжал между двумя машинами в разных сетях. За неделю до переезда TTL был снижен с 3600 до 300, в ночь X запись переключена, старый сервер оставлен включённым. К обеду в поддержку пришло больше десятка обращений: «не открывается».

Что происходило

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

dig +short A example.org            # что видит сама машина
dig +trace A example.org | tail -5  # где ломается цепочка
curl -sS 'https://dns.google/resolve?name=example.org&type=A'

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

Как увидеть это заранее

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

Что помогло в этот раз

На старом IP мы подняли минимальный реверс-прокси, который отвечал 503 с понятным телом и Retry-After, — вместо таймаута соединения. Это не ускорило распространение DNS, зато превратило «страница не открывается» в понятное сообщение и сняло половину обращений.

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

Что бы сделал иначе

← На главную · Архив