Propagation DNS не ломается сам: обычно ломают TTL, кеши и ожидания

Propagation DNS не ломается сам: обычно ломают TTL, кеши и ожидания

Давайте разберем флоу запроса. Рекурсор сначала смотрит в свой кеш, потом идет к авторитативным серверам, а дальше ответ может застрять в промежуточных резолверах, на хостах и даже в приложении. Поэтому «запись уже изменилась» и «изменение видно везде» — это разные состояния.

Что проверять по порядку:
• TTL у старой записи и реальный возраст кеша
• авторитативный ответ на всех NS, а не только на одном
• negative caching для NXDOMAIN и SOA.MINIMUM
• CDN, балансировщики и локальные stub-resolver’ы
• нет ли дублирующих зон и split-horizon, где вы смотрите не туда

Если изменение срочное, уменьшают TTL заранее, ждут его истечения, потом вносят правку. Но это не магия: старые резолверы все равно будут жить по своему кешу до конца срока. Исключаем Human Error через автоматизацию: одинаковая конфигурация на всех NS, проверка делегирования, сравнение answer section и serial.

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