Propagation — это не магия DNS, а предсказуемая задержка между слоями кэша

Propagation — это не магия DNS, а предсказуемая задержка между слоями кэша

Давайте разберем флоу запроса. Изменение попадает в primary, затем его видят secondary, после чего ответ живёт в resolver-кэше у клиента, у провайдера и иногда в промежуточных системах. На каждом этапе действует свой TTL, а «не распространяется» часто означает: где-то ещё жив старый кэш.

Проверяем по порядку:
— SOA/serial: дошла ли зона до всех authoritative;
— AXFR/IXFR и логи secondary: нет ли провала репликации;
— TTL у старых записей: низкий TTL помогает только до смены, а не после неё;
— negative caching: NXDOMAIN тоже кэшируется и умеет мешать.

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

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