Propagation в DNS не ломается магией: ломается предсказуемостью изменений

Propagation в DNS не ломается магией: ломается предсказуемостью изменений

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

Что проверять в первую очередь:
• TTL у старой записи и у нового значения
• SOA serial и факт реальной репликации зоны
• NS-набор: одинаков ли он на всех авторитативных серверах
• отсутствие лишнего кеша у резолвера, CDN или промежуточного прокси

Если изменения застряли, ищите не в «DNS вообще», а в конкретном участке флоу: зона обновилась, но secondary не получил AXFR/IXFR; NS указывает на сервер, который еще не обслуживает новый контент; клиент сидит на агрессивном кэше и честно живет по своему TTL. Стабильность DNS — это фундамент, а не опция.

Исключаем Human Error через автоматизацию: единый пайплайн публикации, проверка serial после деплоя, контроль ответов с каждого авторитативного узла и запрет ручных правок мимо системы. Тогда propagation перестает быть лотереей и превращается в измеряемый процесс.