Начиная с сегодняшнего дня, Cloudflare Internal DNS становится общедоступным. Cloudflare Internal DNS предоставляет авторитативный и рекурсивный DNS для частных сетей, используя ту же глобальную сеть и плоскость управления, которые клиенты уже применяют для публичного DNS, Zero Trust, сетевых и прикладных сервисов.
Внутренний DNS (также называемый частным DNS) — один из последних элементов корпоративной инфраструктуры, который всё ещё управляется отдельно от остальной сети. Многие организации используют одну платформу для публичного DNS, другую — для внутреннего DNS, а внутри каждого облачного окружения применяют облачные DNS-сервисы с отдельными политиками безопасности поверх них. Ни одна из этих систем не имеет общей плоскости управления. Split-horizon DNS добавляет ещё один уровень сложности, часто требуя синхронизации нескольких DNS-сред, чтобы внутренние и внешние пользователи получали разные ответы для одного и того же имени хоста. Когда эти системы расходятся, происходят сбои.
С Cloudflare Internal DNS вы получаете единую платформу для управления публичными и частными DNS-ресурсами, применяя политики DNS и получая видимость всего вашего DNS-стека. Для корпоративных клиентов это включено в Cloudflare Gateway без дополнительной платы.
Почему клиенты внедряют Internal DNS
Консолидация операций DNS. Публичный и частный DNS работают на одной платформе, с одним API, одной аудиторской записью и одним местом для настройки политик. Уходят циклы обновления оборудования и узкие места масштабирования, присущие устаревшим DNS-решениям.
Упрощение split-horizon DNS. Внутреннее и внешнее разрешение определяются как отдельные представления (view) над общими зонами, управляемые из единой плоскости управления. Нет параллельных систем, которые нужно синхронизировать, а значит, нет и расхождений, которые нужно отслеживать.
Распространение Zero Trust на DNS. Политики резолвера определяют, какие пользователи и устройства используют какое представление, применяемые тем же Cloudflare Gateway, который уже управляет остальным трафиком. Разрешение частных имен перестаёт быть брешью в архитектуре Zero Trust.
Модернизация устаревшей инфраструктуры. Откажитесь от аппаратных устройств, устаревших DNS-серверов и облачных резолверов. Cloudflare Internal DNS работает на инфраструктуре, стоящей за 1.1.1.1, без необходимости устанавливать оборудование или выделять мощности.
Что мы создали
Cloudflare Internal DNS состоит из двух компонентов: Gateway Resolver и Internal Authoritative DNS. Авторитативное управление зонами — это другая задача, нежели обеспечение безопасности DNS и маршрутизация политик.
Gateway Resolver отвечает за рекурсивное разрешение и оценку политик. Запущенный в 2020 году и работающий на базе 1.1.1.1 для публичного разрешения, он оснащён встроенным механизмом политик, который может фильтровать DNS-запросы и перенаправлять их на различные вышестоящие источники — всё на основе гибких выражений, с всесторонним логированием и аудитом через единую панель мониторинга.
Internal Authoritative DNS обслуживает записи для внутренних зон, построенных на той же авторитативной платформе, которую Cloudflare использует уже более десяти лет и которая обслуживает больше доменов, чем любой другой провайдер.
Существует три основных объекта, с которыми работают клиенты:
- Внутренние зоны (Internal Zones) содержат авторитативные записи для частных ресурсов: приложения для конкретных сред, конечные точки сервисов, базы данных.
- Представления DNS (DNS Views) группируют зоны в контекст разрешения, который должна видеть конкретная группа пользователей или устройств. Именно это позволяет реализовать split-horizon без параллельных систем.
- Политики резолвера (Resolver Policies) находятся в Gateway и направляют соответствующие запросы к конкретному представлению.
Ссылки на зоны позволяют администраторам повторно использовать общую зону в нескольких представлениях, не копируя её записи в каждое из них. Распространённая зона, например intranet.local, определяется один раз и ссылается на неё везде, где это необходимо — это отличие конфигурации, не повторяющей себя (DRY), от дублированной и подверженной расхождениям настройки, которую обычно требует split-horizon.
Как разрешается запрос
DNS-запрос от клиента сначала попадает в Gateway Resolver, где оценивается политика. Оттуда происходит одно из трёх действий. Если политика резолвера совпадает и указывает на внутреннее представление, запрос направляется в Internal Authoritative DNS и получает ответ из зон соответствующего представления. Если политика блокирует запрос, он отбрасывается на уровне резолвера. В противном случае запрос следует по публичному пути, где 1.1.1.1 разрешает его через иерархию публичного DNS. Представления также могут возвращаться к публичному разрешению, если имя не найдено внутри, поэтому один резолвер может обслуживать как частные, так и публичные имена, без необходимости для клиента знать, какое из них используется.
Как распространяется изменение
Изменения записей проходят предсказуемый, высокоскоростной путь от ввода до границы сети.
Каждое изменение поступает через один и тот же DNS Records API, независимо от того, было ли оно сделано через панель управления, Terraform или прямой вызов API. Этот единый вход означает, что существует только один путь записи, который нужно анализировать и аудировать, независимо от способа внесения изменения. Изменение сохраняется в основных центрах обработки данных Cloudflare для обеспечения долговечности и проверяется перед распространением.
Затем изменения реплицируются по глобальной сети Cloudflare, а соответствующие кэшированные записи аннулируются по мере поступления обновлений, поэтому отредактированные записи вступают в силу за секунды, не дожидаясь истечения TTL.
Начало работы
Если вы корпоративный клиент, использующий Cloudflare Gateway, Internal DNS уже доступен вам. Откройте панель управления Cloudflare, перейдите в Networking, затем Internal DNS.
Настройка Internal DNS обычно включает три шага: создание зоны, создание представления и определение политики резолвера, которая определяет, какие пользователи и устройства должны разрешать запросы через это представление.
Создайте внутреннюю зону и первую внутреннюю запись:
Затем создайте представление DNS и свяжите с ним вашу зону:
Наконец, создайте политику резолвера Gateway в панели управления Zero Trust, которая направляет соответствующий трафик к вашему представлению. Создайте местоположение Gateway, задайте условия, выберите Internal DNS View в качестве метода разрешения и выберите ваше представление. Вот и всё. Запросы, соответствующие вашей политике, теперь будут разрешаться через ваши внутренние зоны.
Поддержка Terraform доступна, и поскольку Terraform записывает через тот же DNS Records API, что и всё остальное, изменения в инфраструктуре как коде проходят тот же путь приёма и распространения. Полная документация и сквозные примеры конфигураций доступны в нашей документации для разработчиков.
Internal DNS как часть Connectivity Cloud
Internal DNS работает с любым методом подключения Cloudflare, который направляет DNS-трафик через Gateway Resolver, включая Cloudflare One Client (ранее WARP), DNS через HTTPS (DoH), DNS через TLS (DoT), стандартный DNS на порту 53, развёртывания PAC-файлов и Cloudflare WAN.
Для организаций, использующих Cloudflare WAN, каждое устройство в подключённой сети может разрешать внутренние имена хостов через Cloudflare без необходимости установки Cloudflare One Client на отдельных устройствах. Результат — согласованный DNS-опыт для удалённых пользователей, филиалов, центров обработки данных и облачных сред с использованием единой плоскости управления.
Что ещё более важно, Internal DNS — это не отдельный DNS-сервис. Он расширяет ту же платформу Connectivity Cloud, которую организации уже используют для защиты пользователей с помощью Zero Trust, подключения сетей через Cloudflare WAN, ускорения приложений и защиты интернет-сервисов.
Перенос частного DNS в ту же глобальную сеть, что и всё остальное, — это лишь отправная точка. Более тесная интеграция DNS, сетевых сервисов и политик Zero Trust — вот куда мы движемся дальше, чтобы разрешение внутреннего имени хоста, доступ к сервису за ним и контроль за тем, кому разрешён доступ, стали решениями, принимаемыми через единую платформу, а не через множество несвязанных систем.