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

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

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

Что проверять перед и после правки:
— TTL у RRset, а не только у одной записи
— отрицательный кеш для NXDOMAIN и NODATA
— SOA serial и корректность зоны на secondary
— время жизни кеша у внутренних рекурсоров
— нет ли разных ответов у разных авторитетных серверов

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

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