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

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

Публичный DNS снимает часть операционной нагрузки, но забирает контроль над тем, как именно живёт зона. Давайте разберем флоу запроса: клиент идёт к anycast-узлам провайдера, а дальше вы зависите от его политики TTL, API, ACL и скорости распространения изменений.

Перед подключением проверьте:
— поддерживаются ли нужные RR-типов, DNSSEC, CAA, ALIAS/ANAME;
— можно ли ограничить доступ к API и журналировать изменения;
— как устроены rollback и экспорт зоны;
— есть ли ограничения на частоту апдейтов и размер зоны.

Отдельный риск — смешанная модель, когда часть записей живёт у провайдера, а часть у вас. В такой схеме легко получить рассинхрон NS, забытый glue или «временный» CNAME, который потом годами маскирует архитектурную ошибку. Проверим влияние на RTT и консистентность зон: любая лишняя прослойка между change request и authoritative answer повышает цену ошибки.

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