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

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

Публичный провайдер снимает операционную нагрузку, но вместе с ней забирает часть предсказуемости. Давайте разберем флоу запроса: авторитативный ответ проходит через чужую инфраструктуру, а значит важны не только zone data, но и политика очередей, лимиты, обработка DNSSEC и поведение при пиках.

На практике проверяют не «есть ли запись», а:
— поддерживает ли провайдер нужные типы RR и ALIAS/ANAME-логику;
— как ведет себя negative caching и SOA minimum;
— можно ли задать TTL без скрытых ограничений;
— есть ли нормальный API, audit log и раздельные роли;
— как устроен rollback, если зона уехала в неконсистентное состояние.

Отдельная зона риска — делегирование и split-horizon. Публичный DNS плохо переносит костыли вида «одна зона для всего мира и ручные исключения в голове у дежурного». Если нужен разный ответ по сетям, это должно быть оформлено архитектурно: отдельные зоны, четкие NS-схемы, понятные ACL и тестируемый процесс публикации.

Проверим влияние на RTT и консистентность зон. Для критичных имен смотрят не только на апдейты у провайдера, но и на реальное распространение по anycast-сети, SOA serial, поведение secondary и возможность быстро доказать, что ответ одинаков на всех точках.

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