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

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

У публичных провайдеров одна общая ловушка: вы делегируете не только публикацию записей, но и часть операционной дисциплины. Давайте разберем флоу запроса: от правки в панели до распространения по anycast-сети проходит время, и именно здесь всплывают задержки, кэш и особенности TTL.

Проверяйте три вещи до вноса изменений:
— как провайдер обрабатывает SOA, serial и AXFR/IXFR;
— есть ли гарантии по API-лимитам и очередям на публикацию;
— что происходит при rollback: мгновенный откат, новая версия зоны или ручная модерация.

Отдельный риск — «удобные» функции, которые ломают предсказуемость. Автопривязка CDN, скрытая нормализация NS, принудительное flattening для apex-записей и оптимизация ответов могут менять поведение зоны без явного изменения конфигурации. В итоге диагностика упирается не в DNS, а в интерфейс провайдера и его внутренние правила. Исключаем Human Error через автоматизацию: фиксируйте зону в Git, сравнивайте выгрузку с эталоном и валидируйте ответы из разных резолверов.

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