Cloudflare запустила Internal DNS — продукт, который размещает частные DNS-зоны на той же глобальной сети и под той же панелью управления, что и публичные DNS-зоны предприятия. Вместо раздельных систем для «внешних» и «внутренних» доменов компания предлагает единый API, один дашборд и один движок политик для каждого DNS-запроса.
Как это работает сегодня
В типовой корпоративной архитектуре публичные и приватные DNS-зоны живут раздельно. Публичная DNS обслуживает сервисы, доступные из интернета. Приватная — внутренние ресурсы (БД, корпоративные приложения), которые не должны быть видны снаружи. При этом частная DNS зачастую размазана по on-premise-апплаенсам, облачным резолверам и split-horizon-схемам, где одно и то же имя разрешается по-разному изнутри и извне сети. Всё это требует постоянной ручной синхронизации между филиалами, штаб-квартирой и облаками.
Что предлагает Cloudflare
Вместо того чтобы плодить копии зон, Cloudflare Internal DNS заменяет их одной авторитетной копией, разделённой на логические представления (views). Resolver (Cloudflare Gateway) оценивает каждый запрос до того, как он попадёт в зону: Zero Trust-политики проверяются в первую очередь.
Архитектура:
- Gateway как единый резолвер — клиенты подключаются через WARP, DNS-over-HTTPS, DNS-over-TLS или классический DNS. Gateway проверяет политики, затем направляет запрос к нужному DNS-представлению.
- Внутренние зоны без публичного пути — они не получают публичных NS-записей, доступны только через Gateway, который оценивает каждый запрос перед резолвингом.
- Одно имя, разные ответы — одно и то же внутреннее имя может возвращать разные IP в зависимости от источника запроса: филиал, ЦОД или облако. При этом не нужно поддерживать отдельные резолверы, условные форвардеры или дублировать файлы зон.
Выбор представления управляется политиками Gateway: учитываются source IP, идентификатор устройства, сетевое расположение. Представление — не отдельная инфраструктура, а просто логическая группа внутренних зон.
Замена split-horizon DNS
Split-horizon — самая частая причина миграции на Internal DNS. В типичной старой схеме каждое подразделение держит свои копии одних и тех же зон с условными форвардерами — и всё это рассыпается, теряет актуальность и требует постоянной поддержки.
Internal DNS сворачивает дубликаты в одну зону, а различия задаёт через views. Пример: для wiki.corp.internal штаб-квартира получает один IP, филиал — другой, но сама зона corp.internal существует в единственном экземпляре.
Когда пригодится
Cloudflare называет три типовых сценария: консолидация split-horizon DNS, единая DNS для multi-cloud-сред (вместо отдельных DNS-платформ в каждом облаке) и распространение Zero Trust на внутренние имена (те же политики Gateway, что работают для интернет-трафика, теперь применяются к внутренним корпоративным адресам).
Администраторам на заметку
Сама миграция, по словам Cloudflare, процедурная, а не архитектурная: «клиентам нужно продумать API-права, связность и то, как существующие локальные правила форвардинга взаимодействуют с Gateway». Обе среды рекомендуется запускать параллельно до завершения перехода. Для российских компаний, которые уже используют Cloudflare для публичной DNS (например, для защиты от DDoS или кэширования), Internal DNS может стать логичным расширением — при условии, что схема резолвинга не конфликтует с требованиями к локализации данных.
Источник: networkworld.com