Propagation в DNS ломается не магией, а предсказуемыми задержками и ошибками делегирования

Propagation в DNS ломается не магией, а предсказуемыми задержками и ошибками делегирования

Давайте разберем флоу запроса. Резолвер не «видит» изменения мгновенно: он живет по TTL кэша, негативного кэша и собственной стратегии повторных запросов. Если зона обновилась, а клиент еще получает старые ответы, это обычно не проблема DNS как такового, а конфликт кэшей, SOA-параметров и несинхронных NS.

Проверяем по порядку:
— совпадают ли NS у делегирования и в самой зоне;
— есть ли у всех авторитативных серверов одинаковый serial;
— не слишком ли высок TTL у A/AAAA, NS и SOA;
— не остался ли старый ответ в промежуточном резолвере или у клиента.
Стабильность DNS — это фундамент, а не опция.

Отдельно смотрим на отрицательное кеширование: если запись только что добавили, а клиент продолжает получать NXDOMAIN, виноват не «плохой интернет», а TTL в SOA minimum / negative cache TTL. Еще один классический костыль — менять запись на одном NS и надеяться, что остальные «догонят». Не догонят, если сломан pipeline синхронизации.

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