Мониторинг зелёный. Балансировщик отвечает. Сертификат на месте. А пользователи в чате пишут, что портала больше нет. Через сорок минут причина находится — и звучит она до обидного просто. Для portal.corp.example часть клиентов получает новый внутренний адрес, часть — старый, выведенный из эксплуатации на прошлой неделе. Приложение живо. Сеть «как будто» жива. Разъехался DNS.

Это не невезение, а закономерное следствие того, как устроено большинство инфраструктур. Публичная зона живёт у регистратора, внутренняя — в службе каталогов, отдельно лежат частные зоны в облаке, отдельно стоит резолвер на шлюзе «для фильтрации», плюс ещё один DNS работает внутри контейнерной платформы. У каждого слоя свои люди, свой срок жизни записей и свой способ что‑то поменять. Пока всё совпадает — тишина. Стоит обновить один контур и забыть про второй, как симптомы начинают маскироваться подо что угодно: «тупит балансировщик», «VPN виноват», «1С тормозит».

Вокруг при этом давно выстроен принцип «нулевого доверия»: проверки устройств, красивые схемы доступа, политики на каждый чих. DNS в эти схемы часто так и не вошёл. А зря — именно резолвер первым решает, существует ли для пользователя сервис и какой адрес считать правильным.

Поводом для статьи стал анонс Cloudflare Internal DNS от 20 июля 2026 года: сервис вышел в общую доступность для корпоративных клиентов Cloudflare Gateway. Вендор собрал публичный и внутренний DNS рядом с защитным резолвером и описал систему через три объекта — внутренние зоны, представления (views) и политики резолвера. Это не новый стандарт DNS и не единственно возможная реализация. Но как архитектурная рамка модель полезна: она заставляет отдельно описать данные, аудитории и правила выбора ответа.

Дальше разберём эту идею без требования покупать конкретную платформу: что можно перенести в свой гибридный контур, где понадобятся BIND, Windows DNS или облачные зоны, а какие продуктовые возможности одной настройкой честно не заменить.

Почему DNS снова становится проблемой

В типичной гибридной инфраструктуре одновременно живут пять слоёв:

  • Публичный авторитетный DNS — то, что видит интернет: почта, сайт, внешние точки входа, выпуск сертификатов.

  • Внутренний DNS — зоны службы каталогов, классический сервер имён или «две виртуалки в серверной».

  • Облачный DNS — частные зоны в каждом облаке, в разных кабинетах и консолях.

  • Защитный DNS — политики интернет‑шлюза, шифрованные запросы из браузера, иногда отдельный резолвер на филиале.

  • Платформенный DNS — резолвер контейнерного кластера, механизмы обнаружения сервисов, иногда собственное пространство имён сервисной сетки.

У каждого слоя свои средства управления, свои привычки к TTL, свой журнал изменений (или его отсутствие) и свои ответственные. Когда одно и то же имя снаружи и внутри должно указывать на разные адреса, синхронизацию обычно держат на дисциплине и ночных заданиях. Дисциплины рано или поздно не хватает.

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

Параллельно выросла роль DNS в безопасности. Резолвер видит запрошенное имя до того, как установится соединение с целевым адресом: к каким внешним сервисам обращается сервер, какое внутреннее имя запросило устройство, куда «полез» стенд. Межсетевой экран при этом остаётся обязательным уровнем контроля — DNS его не заменяет и права на подключение не доказывает. Но если политика безопасности действует только на веб‑прокси, остальные протоколы и внутренние имена выпадают из картины целиком.

Контур данных и контур управления

Разделение простое, но его редко проговаривают вслух.

Контур данных — это путь самого запроса: протокол и порты, рекурсия, авторитетный ответ, кэш, расширения, время ответа.

Контур управления отвечает на другие вопросы:

  • какие зоны существуют;

  • какие записи в них считаются верными;

  • кто какой набор зон видит;

  • какие запросы блокируются, журналируются или уводятся на заглушку;

  • как изменение доходит до всех резолверов;

  • можно ли потом установить, кто, что и когда менял.

Межсетевой экран говорит: «этому субъекту разрешён доступ на порт 443 по такому‑то адресу». DNS отвечает на другой вопрос: «какому адресу соответствует это имя в данном контексте — и существует ли оно здесь вообще».

Отсюда и заголовок. В гибридных сетях доступ всё чаще завязан на имя: корпоративные приложения, закрытые каналы в облако, имена в сертификатах, служебные сервисы. Резолвер срабатывает раньше многих средств защиты. Размыт контур управления DNS — размыта и остальная модель безопасности.

Три опорных элемента модели

Под ними лежат два технических слоя: Gateway Resolver выполняет рекурсию и применяет политики, Internal Authoritative DNS отвечает за внутренние зоны. Связывают их три объекта. Названия продуктовые, но разделение ответственности переносится и на другие стеки.

1. Внутренняя зона

Хранит записи для ресурсов, которые не должны разрешаться через публичные авторитетные серверы: базы данных, хранилища секретов, служебные панели, внутренние имена сервисов.

На практике это может быть основная зона на классическом DNS‑сервере, зона, интегрированная со службой каталогов, частная зона в облаке или внутренняя зона у внешнего DNS‑провайдера.

Важны не файлы на диске, а авторитетность и изоляция: внешний клиент не должен получить ответ из частной зоны или выгрузить её целиком из‑за ошибки в настройках.

В Cloudflare внутренним зонам не назначают публичные серверы имён — запросить их можно только через Gateway Resolver и выбранное представление. Если собираете систему сами, ту же границу придётся обеспечить сетевой доступностью, списками доступа и запретом публичной делегации.

2. Представление (view) — кому какой ответ

В исходной реализации представление — это логическая группа внутренних зон, которую политика резолвера выбирает для конкретного запроса. Близкую роль играют views в BIND, области зоны и политики Windows DNS либо просто раздельные наборы зон за разными резолверами.

Аудитории бывают, например, такие:

  • сотрудники в офисе или в корпоративной VPN;

  • подрядчики;

  • автоматизация продуктивной среды — сборки, конвейеры выкладки;

  • тестовые стенды и разработка;

  • партнёрский доступ;

  • доступ «только в интернет», без внутренней сети.

Представления позволяют аккуратно развести разные ответы на одно имя для разных контекстов. Но согласованность данных они не гарантируют: если в двух представлениях лежат две независимые зоны с одинаковым именем, разъехаться они могут ровно так же.

В модели Cloudflare одну внутреннюю зону можно подключить к нескольким представлениям. Есть и ссылочные зоны — если в основной зоне записи нет, поиск продолжится в связанной. Так общий набор записей определяется один раз и переиспользуется. В других реализациях того же результата добиваются шаблонированием, общим источником данных или механизмом вроде in‑view в BIND.

3. Политика резолвера

Политика отвечает прежде всего за маршрутизацию: куда отправить запрос — во внутреннее представление, на собственный вышестоящий резолвер или в публичную рекурсию. Условие может учитывать имя, сеть‑источник, площадку, а в интегрированных Zero Trust‑платформах ещё и пользователя с состоянием устройства.

Блокировка и фильтрация — соседний, но отдельный слой политик. Порядок обработки в конкретном продукте лучше проверять по документации. В общем случае с запросом можно сделать четыре вещи: направить в нужное представление, на вышестоящий сервер или на условную пересылку; заблокировать; записать в журнал с контекстом; переписать ответ — приём редкий и на любителя.

Логика в общем виде:

DNS-фильтр          ->  разрешить запрос или заблокировать
resolver policy     ->  выбрать внутреннее представление или другой резолвер
нет совпадения      ->  публичная рекурсия по правилам организации
отдельная зона      ->  пересылка в DNS службы каталогов или партнёра

Три объекта дают минимальную логическую модель. Чтобы она заработала в проде, к ней обязательно добавляются канал изменений, аудит, резервирование и наблюдаемость.

Минимальная модель контура управления DNS Три объекта связывают контекст запроса с авторитетными данными; эксплуатационные слои делают модель управляемой.

Как обрабатывается запрос

  1. Клиент — ноутбук, сервер, маршрутизатор филиала — обращается к корпоративному резолверу. Транспортом может быть обычный DNS, DNS over TLS или DNS over HTTPS.

  2. Политика фильтрации проверяет, разрешён ли запрос.

  3. Политика резолвера выбирает внутреннее представление, собственный вышестоящий DNS или публичную рекурсию.

  4. Во внутреннем представлении находится наиболее подходящая авторитетная зона, в ней ищется запись. В реализации Cloudflare следом может проверяться ссылочная зона.

  5. Если записи нет, поведение задаётся явно: вернуть отрицательный ответ либо уйти в разрешённый публичный fallback. В Cloudflare этот переключатель относится к resolver policy — универсальным свойством DNS views он не является.

  6. В гибридных схемах отдельные пространства имён службы каталогов, партнёра или облака нередко остаются на прежних серверах и подключаются условной пересылкой.

Путь DNS‑запроса через фильтрацию, resolver policy и внутреннее view Фильтрация отвечает «можно ли», resolver policy — “где разрешать”, view — «какие зоны использовать».

Клиенту при этом не нужно решать, внутреннее имя он спрашивает или публичное: точка входа одна, путь запроса выбирает политика.

Где клиент

Откуда берётся корпоративный DNS

Офис

Параметры DHCP указывают на корпоративные резолверы

Удалённая работа

Клиент удалённого доступа или полный туннель

Филиал

Перехват DNS или локальный пересыльник на центральный резолвер

Серверы

Явная настройка в учёте; «зашитый» 8.8.8.8 — технический долг

Контейнерный кластер

Собственный резолвер кластера и пересылка корпоративных зон наружу

Если заметная доля устройств обходит корпоративный резолвер, никакого контура управления нет — есть только его описание в документации.

Как вносится изменение

Контур управления работает ровно до тех пор, пока изменения идут одним согласованным путём.

У Cloudflare схема такая: панель, Terraform и прямой вызов API сходятся в одном DNS Records API; данные проверяются, сохраняются, расходятся по сети, затронутый кэш инвалидируется. Переносимое здесь — не конкретный API, а единый записывающий тракт.

Целевая схема у себя:

человек или конвейер
  -> инфраструктура как код, консоль или API-клиент
    -> проверка
      -> надёжное хранилище
        -> репликация на резолверы и авторитетные узлы
          -> управляемая доставка изменений и работа с кэшем
            -> запись в журнал аудита

Единый путь изменения DNS Интерфейсов может быть несколько, независимых состояний быть не должно.

Как делать не надо: править вручную на первом сервере имён, а на втором «как‑нибудь потом»; держать таблицу в роли главного реестра и скрипт, который иногда запускают; разрешать сетевой команде править один продукт, облачной — другой, а согласовывать всё это в мессенджере.

Единый канал не запрещает графическую консоль. Он требует, чтобы консоль, API и код инфраструктуры не создавали независимые состояния: изменения проходят одинаковые проверки и попадают в общий журнал. Тогда вопрос «кто сменил адрес?» перестаёт быть расследованием.

Сюда же хорошо ложится учёт инфраструктуры — например, NetBox — как слой намерения. В учёте есть адрес, устройство, сервис, метки среды. Конвейер формирует из этого желаемый набор DNS‑записей. DNS применяет отличия от текущего состояния. А если кто‑то полез «править на пять минут» руками, срабатывает контроль расхождений.

DNS исполняет желаемое состояние. Учёт отвечает на вопрос, зачем запись вообще существует.

Внешний и внутренний ответ — без двух параллельных миров

Классическая боль — две независимые авторитетные системы, которые «должны» синхронизироваться. На практике синхронизация отстаёт или ломается.

В продуктовой модели из исходной статьи это устроено так:

  • публичная авторитетная зона — то, что отдано в интернет; в Cloudflare она не включается во внутреннее view;

  • внутренние представления — группы внутренних зон с другими ответами на те же имена, где это нужно, плюс полностью внутренние имена;

  • одна внутренняя зона может входить в несколько представлений;

  • общие записи выносятся в ссылочную зону, которую проверяют, если в основной ничего не нашлось.

Если собираете сами, такой механизм придётся проектировать отдельно. Само слово view дублирование не устраняет: BIND спокойно позволит назначить зоне одного имени разные файлы данных в разных views.

Правила гигиены:

  • Частные зоны не делегируются на публичные серверы имён.

  • Передача зоны целиком (AXFR и аналоги) — только по жёсткому списку доступа. Лучше вообще управлять записями через единый интерфейс.

  • Публичный fallback включается осознанно. Для чувствительной внутренней зоны отрицательный ответ не должен незаметно превращаться в запрос к публичной иерархии.

  • В регламенте диагностики должно быть ясно, из какого представления вы сейчас спрашиваете DNS. С домашнего резолвера легко собрать совершенно ложную картину.

  • Если команда к представлениям ещё не готова, разведите имена явно: app.example.com снаружи и app.internal.example.com внутри. Представления — мощный инструмент, а не обязательная цель «на вчера».

DNS в модели «нулевого доверия»

В презентациях «нулевое доверие» обычно сводят к веб‑приложениям. На практике рядом живут общие каталоги, удалённый рабочий стол, SSH, порты СУБД и «просто адрес, который когда‑то прописали руками».

Обычный DNS‑сервер различает клиентов по адресу сети, интерфейсу или криптографическому ключу. Политика по конкретному пользователю и состоянию устройства появляется только там, где резолвер интегрирован с клиентским агентом, каталогом и платформой доступа. Именно такую интеграцию и показывает Cloudflare.

Даже в этом случае DNS не заменяет ни авторизацию в приложении, ни сетевой контроль. Но помогает:

  • ограничить разведку сети — подрядчик не узнает имя базы, которая ему не нужна;

  • раньше заметить аномалию — например, внезапный поток запросов к хранилищу резервных копий;

  • связать запрос имени с контекстом пользователя или устройства, если платформа действительно передаёт этот контекст резолверу;

  • быстрее отключить опасное имя политикой, чем переписывать десятки списков доступа.

Как это выглядит в правилах: группа «внешние подрядчики» получает представление без зон продуктивных данных; устройство без шифрования диска — урезанное представление, только обновления и средства управления; технологическая сеть работает по белому списку имён, остальное запрещено по умолчанию; при срабатывании индикатора угрозы клиент получает ответ‑заглушку, а система мониторинга событий — сигнал.

И отдельно: журналы DNS — это фактически опись поведения пользователей и систем. Хранить их нужно ограниченное время и выдавать по ролям, как любые чувствительные данные.

Как собрать модель без обязательной «коробки» одного вендора

Готовые облачные и SASE‑платформы интересны как образец упаковки: рекурсия с политиками, внутренний авторитетный DNS, представления и один интерфейс рядом с публичным DNS. Ориентир удобный. Но ту же логику можно собрать и на земле.

Вариант А. Классическая схема, приведённая в порядок. Рекурсия — Unbound или BIND. Авторитетные зоны — BIND, PowerDNS или DNS службы каталогов. Разные ответы — views в BIND, экспериментальные views в PowerDNS 5.0 либо области зон и политики Windows DNS. Политики ответов — RPZ и списки доступа. Изменения — автоматизация и зоны в системе контроля версий.

Отдельно про PowerDNS 5.0: views по сети‑источнику там появились, но документация помечает функцию как экспериментальную и доступную только с LMDB backend. Полным эквивалентом Cloudflare это не станет — выбор по личности и состоянию устройства, рекурсивная маршрутизация и защитная фильтрация всё равно потребуют других компонентов. В более ранних версиях аудитории придётся разводить архитектурой экземпляров, прокси‑слоем или внешней политикой.

Вариант Б. DNS как код. Авторитетный сервер с API, рекурсия с механизмом политик, конвейер проверяет синтаксис зон, изменение = запрос на слияние в репозитории.

Вариант В. Гибрид с облаком. Частные зоны по средам, гибридное разрешение имён и выделенные точки резолва, аккуратные пересыльники на свою площадку, для пользователей — один корпоративный защитный DNS. Риск прежний: без общей модели снова получится зоопарк из нескольких облаков и службы каталогов.

Вариант Г. Контейнерный кластер — это не вся компания. Резолвер кластера хорошо обслуживает внутренности кластера и сам по себе корпоративным контуром DNS не становится. Нужны пересылка корпоративных зон, явная граница «кто вправе создавать внешние записи» и запрет на ситуацию, когда у каждой команды своя правда о продуктивной среде.

Покупаете вы готовую платформу или собираете связку из BIND и службы каталогов, контрольный список один: зоны, представления, политики, единый канал изменений, наблюдаемость.

Типичные отказы

1. Резолвер как единая точка отказа. Упал DNS — для пользователя «упала сеть». Резервируйте по узлам и площадкам, проверяйте, что клиенты действительно переключаются, держите ограниченный аварийный путь к критичным системам управления. Надежда «все временно пойдут по IP» обычно не оправдывается: имена зашиты в сертификаты, каталоги и зависимости приложений.

2. Политика заблокировала администраторов. Особенно неприятно, если правила завязаны на учётные записи. Заведите аварийное представление и отдельный обходной путь для админов, а внедряйте в два этапа: сначала только журнал, потом запрет.

3. Отрицательное кэширование. Клиент запомнил ответ «имени нет», хотя запись уже добавили. Выставляйте осмысленные TTL, разберитесь с параметрами зоны и заранее проверьте, чем сбрасывать кэш.

4. Клиент попал не в то представление. Подрядчик видит продуктивные имена — или, наоборот, инженер получает адрес стенда вместо боя. Прогоняйте политики автотестами, раскатывайте на пилотную группу.

5. Часть клиентов живёт своей жизнью. Треть устройств по‑прежнему ходит в 8.8.8.8 или на домашний маршрутизатор. Заведите метрику доли корпоративного DNS, ограничьте это на уровне сети и объясните пользователям, зачем.

6. Циклическая зависимость при старте. Гипервизор и СХД обращаются по именам, а DNS развёрнут на них же. Вынесите служебный DNS из этой зависимости и задокументируйте адреса управления для аварийного доступа.

7. Двойной ввод изменений. Автоматизация и «быстрая правка руками». Включите контроль расхождений с оповещениями и урежьте локальные привилегии.

8. Журналы как риск для конфиденциальности. DNS‑лог показывает, кто куда обращался. Ограничьте срок хранения, раздайте доступ по ролям, собирайте минимально необходимый объём.

Что измерять

  • задержку внутренней рекурсии — медиану и «хвост»;

  • долю ответов «имени нет» и ошибок сервера;

  • долю запросов, обслуженных внутренними представлениями;

  • долю клиентов на корпоративном резолвере;

  • время от принятия изменения в репозитории до нового ответа;

  • число расхождений между желаемым и фактическим состоянием;

  • скорость обнаружения инцидентов, где корневая причина — DNS.

Без метрик через год вы снова будете чинить «не открывается портал», глядя в логи балансировщика.

Заключение

Внутренний DNS давно перестал быть подписью к IP‑адресу. В гибридной среде имя участвует в доступе: через него сходятся сервис, маршрут запроса и политика. Пока ответы живут в нескольких несогласованных местах, модель доступа начинается с непредсказуемой карты сети.

Держать в голове достаточно четырёх опор:

  1. Зоны — что считается истиной.

  2. Представления — кому какая истина видна.

  3. Политики резолвера — какой путь и какое представление выбираются.

  4. Один канал изменений — иначе пункты 1–3 снова разъедутся через квартал.

Фильтрация, аудит и наблюдаемость окружают эту модель отдельными слоями.

Cloudflare показывает интегрированную упаковку: внутренний авторитетный DNS, Gateway Resolver, views, resolver policies, единый API и аудит в одной платформе. На обычном стеке воспроизводится архитектурный принцип, но не обязательно все свойства продукта. BIND, PowerDNS 5.0 или Windows DNS дадут разные ответы по сетевому контексту, PowerDNS — управляемый API, RPZ — фильтрацию, репозиторий — проверяемый канал изменений. Интеграция с личностью и состоянием устройства потребует отдельного слоя.

Критерий успеха — не совпадение списка продуктов, а способность за пять минут ответить: какой резолвер получил запрос, какая политика сработала, какое представление и зона дали ответ, кто изменил запись и когда изменение дошло до узлов.

Начать можно без бюджета. Возьмите три точки: ноутбук бухгалтера, сборочный сервер и машину в другом контуре. С каждой выполните один и тот же запрос к ключевым именам. Разные ответы могут оказаться правильным результатом работы политики. Но если никто не может объяснить различие через ожидаемое представление, владельца зоны и журнал изменения — у вас не контур управления, а несколько параллельных историй, которые рано или поздно встретятся в аварийном чате. Сначала карта и владельцы, потом представления и политики, и только затем разговор о новой «коробке».

Если проектируете гибрид или переезд сервисов, закладывайте DNS‑контур сразу: чинить его после того, как разъехались продуктив и VPN, обычно дороже.