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

Публичный DNS решает две задачи: быстро раздать зону и не умереть под пиками запросов. Но у провайдера есть жесткие рамки: не все типы записей, не любой TTL, не всякая схема делегирования. Давайте разберем флоу запроса: клиент → рекурсор → авторитативный узел провайдера → ответ. Любая «оптимизация» вне этого пути обычно превращается в задержки и лишние точки отказа.

Перед миграцией проверьте:
— поддержку DNSSEC, ALIAS/ANAME, CAA, IPv6, hidden primary;
— ограничения на SOA/NS, минимальный TTL и частоту изменений;
— поведение при NXDOMAIN, SERVFAIL и truncation;
— как провайдер распределяет authoritative servers по Anycast и есть ли заметная деградация при отказе площадки.

Отдельный риск — консистентность зон. У некоторых провайдеров изменения применяются не атомарно, и короткий TTL не спасает, если разные узлы отдают разные версии зоны. Поэтому критичные записи лучше менять через staged rollout: сначала низкорисковые поддомены, затем apex и почта. И да, CNAME на apex по-прежнему не лечится магией.

Если провайдер закрывает вам 90% сценариев без ручного тюнинга — это нормальный выбор. Если приходится строить костыли вокруг ограничений API, лучше заранее оценить, кто у вас на самом деле управляет зоной: вы или интерфейс провайдера. Սтабильность DNS — это фундамент, а не опция.