<b>Propagation DNS-записей: почему «не обновилось» чаще всего означает неверную модель кешей</b>

<b>Propagation DNS-записей: почему «не обновилось» чаще всего означает неверную модель кешей</b>

Давайте разберем флоу запроса. Изменение в zone file само по себе ничего не гарантирует: клиент видит ответ только после прохождения authoritative, рекурсивного резолвера и локального кеша. Если хотя бы один слой держит старое значение, вы получаете «пропагацию», хотя на деле это обычная инерция кеширования.

Проверяйте не «где не обновилось», а кто именно отдает старое:
• authoritative-серверы: совпадает ли ответ на всех NS
• SOA serial: дошел ли новый сериал до вторичных
• TTL: не слишком ли велик для планируемой смены
• рекурсоры у провайдеров и на корпоративных DNS: не сидит ли старый ответ в кеше
• negative caching: NXDOMAIN тоже кешируется, и это часто забывают

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

Проверяйте влияние на RTT и консистентность зон: делайте выборку с разных резолверов, сверяйте ответы через dig по NS и по публичным рекурсорам, а не доверяйте одному «у меня уже работает». Исключаем Human Error через автоматизацию.

Если «propagation» затянулся, ищите не магию, а кеш, TTL и расхождение между authoritative и recursive слоями.