<b>Propagation DNS не ломается сама: ищем узкое место в цепочке обновления</b>

<b>Propagation DNS не ломается сама: ищем узкое место в цепочке обновления</b>

Давайте разберем флоу запроса. Изменение проходит не «по интернету», а через конкретные точки: источник зоны, hidden master, secondary, anycast-узлы, кеши рекурсоров и TTL. Если где-то задержка, причина почти всегда локальна: устаревший SOA, несинхронный IXFR/AXFR, слишком длинный кеш у резолвера или ошибки в маршрутизации до авторитетного сервера.

Проверка начинается не с паники, а с трассировки состояния:
— сравните serial на всех NS;
— убедитесь, что SOA refresh/retry/expire не конфликтуют с политикой обновления;
— проверьте, не держит ли рекурсор старый ответ из-за TTL;
— отдельно смотрите на DNSSEC: подпись может обновиться, а валидирующий кеш — нет.

Если изменение «не доехало», ищите не только зону, но и транспорт: нестабильный TCP к secondary, фильтрацию фрагментов, EDNS0-совместимость, асимметричный трафик. Anycast тоже не магия: один POP может уже отвечать новым значением, другой — еще старым, если репликация и health-check живут отдельно.

Исключаем Human Error через автоматизацию: предварительная валидация зоны, staged rollout, контроль serial monotonic increase и обязательный post-change diff на авторитетных серверах. Стабильность DNS — это фундамент, а не опция.