Публичный DNS-провайдер: где заканчивается удобство и начинается риск

Публичный DNS-провайдер: где заканчивается удобство и начинается риск

Давайте разберем флоу запроса. Клиент спрашивает рекурсор, рекурсор — authoritative-сервер провайдера, а дальше в игру вступают их политика TTL, кэширование и Anycast. На бумаге это выглядит просто; в эксплуатации важны ограничения панели, API и то, как быстро меняются записи после правок.

Ключевые проверки перед переносом зоны:
— поддержка CAA, DNSSEC, ALIAS/ANAME и отдельных типов записей;
— поведение при апексе зоны и конфликте с существующими NS;
— лимиты на размер зон, частоту API-операций и число запросов к контрольной панели.

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

Итог простой: не переносите зону вслепую. Сначала тестируйте вторичную зону, затем сценарии отката, потом автоматизируйте проверки SOA, NS и разрешение критичных имён. Исключаем Human Error через автоматизацию.