Propagation в DNS не ломается сам: его почти всегда ломают TTL, кеши и порядок изменений

Propagation в DNS не ломается сам: его почти всегда ломают TTL, кеши и порядок изменений

Давайте разберем флоу запроса. Изменили A/AAAA/CNAME, а часть клиентов еще видит старое значение — это не «магия DNS», а нормальная работа кеширования у рекурсивных резолверов, stub resolver’ов и промежуточных форвардеров.

Чтобы не гадать, проверяйте цепочку целиком:
— authoritative отвечает новым значением?
— SOA serial изменился и зона реально загружена?
— TTL у старой записи не слишком велик?
— нет ли отрицательного кеша из-за NXDOMAIN/SERVFAIL?
— не смотрите ли вы только в один публичный резолвер, который сам кеширует ответ?

Отдельно опасны CNAME-цепочки и NS-делегации: там задержка часто сидит не в самой записи, а в соседнем уровне. Если меняете адрес сервиса, сначала снижайте TTL заранее, потом вносите изменение, затем мониторьте ответы с разных точек и для разных типов запросов. Это банально, но именно так исключаем Human Error через автоматизацию.

Если propagation «завис», ищите не один виноватый сервер, а весь путь ответа: authoritative, кеш, TTL и порядок миграции. Стабильность DNS — это фундамент, а не опция.