Внутренний DNS как контур управления: почему от резолвера зависит больше, чем кажется
Мониторинг показывает норму, балансировщик отвечает, сертификат действует, а пользователи сообщают, что корпоративный портал исчез. Через несколько десятков минут выясняется: приложение работает, сеть доступна, но имя `portal.corp.example` разные группы клиентов разрешают в разные адреса. Часть сотрудников получает новый внутренний IP, а часть - старый сервер, отключённый ещё неделю назад.
Проблема не в случайном сбое и не обязательно в балансировщике. Нарушена связка "имя - адрес". Иными словами, рассинхронизирован DNS.
Почему DNS становится источником крупных аварий
Современная инфраструктура редко использует один-единственный DNS-сервис. Публичные записи размещаются у регистратора или внешнего DNS-провайдера. Внутренние зоны работают в службе каталогов или на отдельных серверах имён. Облачные площадки используют собственные частные зоны, защитные шлюзы фильтруют запросы, а контейнерные платформы поддерживают собственное пространство имён.
У каждого компонента обычно есть отдельная команда, собственные правила изменения записей и разные сроки хранения данных в кэше. Пока все системы согласованы, архитектурная сложность незаметна. Но после изменения только одного слоя начинаются симптомы, которые легко принять за неисправность VPN, сетевого маршрута, балансировщика или бизнес-приложения.
DNS первым отвечает на вопрос: существует ли для конкретного пользователя нужный сервис и какой адрес следует считать правильным. Поэтому резолвер необходимо рассматривать не только как технический справочник, но и как часть контура управления доступом.
Контур данных и контур управления
Полезно разделять две составляющие DNS-архитектуры.
Контур данных отвечает за обработку конкретного запроса. Клиент обращается к резолверу, резолвер определяет нужную зону, применяет правила и возвращает адрес либо сообщение об ошибке.
Контур управления определяет, какие записи существуют, кто имеет право их менять, какие аудитории должны получать разные ответы и как изменения распространяются между системами.
На практике внимание часто уделяют только первому контуру: проверяют доступность DNS-сервера, время ответа и наличие записей. Но аварии нередко возникают именно в контуре управления. Запись может быть формально доступна, однако устареть, оказаться созданной не в той зоне или стать видимой не той группе пользователей.
Три опорных элемента устойчивой модели
1. Внутренние зоны
Внутренняя зона содержит имена, которые не должны публиковаться в интернете: адреса приложений, контроллеров домена, баз данных, внутренних API и административных сервисов.
Важно заранее определить владельца каждой зоны. Если записи одной и той же области одновременно редактируются в Active Directory, облачной консоли и системе автоматизации, неизбежно возникает вопрос: какая версия считается главной?
Надёжная схема предполагает единый источник истины либо чётко зафиксированное распределение полномочий. Например, записи корпоративного домена управляются службой каталогов, а частные имена облачной среды - инфраструктурным кодом. При этом правила делегирования и границы ответственности должны быть документированы.
2. Представления, или views
Одна и та же DNS-зона может возвращать разные ответы разным клиентам. Сотруднику в офисе нужен внутренний адрес портала, внешнему пользователю - публичная точка входа, а серверу в облаке - адрес ближайшего регионального узла.
Механизм views позволяет описать такую логику явно: ответ зависит от сети, идентичности устройства, расположения, подключения через VPN или принадлежности к определённой группе.
Это значительно надёжнее, чем создавать похожие зоны в нескольких местах и рассчитывать, что администраторы синхронно обновят их вручную.
3. Политика резолвера
Резолвер должен не только искать адрес, но и применять правила безопасности и маршрутизации запросов. Политика может запрещать обращение к вредоносным доменам, направлять запросы определённых подразделений в отдельные зоны или блокировать разрешение внутренних имён для неподходящих клиентов.
При этом DNS-фильтрация не заменяет межсетевой экран и контроль доступа. Успешное разрешение имени не означает, что соединение разрешено. DNS показывает намерение и помогает управлять маршрутом, но не доказывает наличие полномочий на подключение к сервису.
Как проходит DNS-запрос
Упрощённая цепочка выглядит следующим образом:
1. Устройство формирует запрос к настроенному резолверу.
2. Резолвер определяет клиента и применимые политики.
3. Запрос сопоставляется с внутренней, публичной или облачной зоной.
4. Выбирается представление, предназначенное данной аудитории.
5. Ответ возвращается клиенту и сохраняется в кэше на срок, заданный TTL.
6. При необходимости запрос передаётся вышестоящему серверу или авторитетному источнику.
Сбой может произойти на любом этапе. Клиент способен использовать неправильный DNS, резолвер - выбрать не ту view, зона - содержать устаревшую запись, а кэш - продолжать отдавать старый адрес ещё несколько часов.
Поэтому проверка должна начинаться не с вопроса "доступен ли сервер?", а с выяснения: какой именно клиент отправил запрос, какому резолверу, по какой политике и из какой зоны был сформирован ответ.
Внутренние и внешние ответы без двух независимых миров
Частая архитектурная ошибка - поддерживать публичный и внутренний DNS как два никак не связанных мира. Внешняя зона обновляется автоматически, внутренняя - вручную; в облаке создаётся третья копия; затем администраторы пытаются устранить расхождения скриптами и периодическими сверками.
Более устойчивый подход - определить единый жизненный цикл имени. Для каждой записи следует знать владельца, назначение, допустимые аудитории, источник данных, срок действия и процедуру удаления.
Это особенно важно при миграциях. Если новый адрес опубликован только в облачной зоне, пользователи, чьи устройства обращаются к DNS службы каталогов, продолжат получать прежнее значение. В результате одна часть инфраструктуры будет работать, а другая - нет, хотя все компоненты по отдельности окажутся исправны.
DNS в модели нулевого доверия
В концепции нулевого доверия проверяется не только сетевое расположение клиента, но и его идентичность, состояние устройства, назначение запроса и контекст доступа. DNS хорошо вписывается в эту модель, поскольку фиксирует, к каким именам обращаются устройства и сервисы.
Например, можно разделить ответы для управляемых рабочих станций, гостевых устройств, серверов сборки и административных узлов. Можно блокировать разрешение подозрительных доменов, направлять отдельные запросы через контролируемые шлюзы и обнаруживать отклонения в поведении приложений.
Однако DNS-политики должны быть частью общей системы, а не единственным механизмом защиты. Необходимо сочетать их с сетевой сегментацией, аутентификацией, контролем исходящих соединений, журналированием и проверкой сертификатов.
Как построить модель без зависимости от одного поставщика
Для такой архитектуры необязательно приобретать единую специализированную платформу. Внутренние зоны могут обслуживаться BIND или Windows DNS, облачные записи - частными зонами соответствующего провайдера, а защитная фильтрация - отдельным резолвером.
Критически важно не наличие одной "коробки", а согласованность компонентов. Следует заранее определить:
- где находится источник истины для каждой зоны;
- кто создаёт и удаляет записи;
- как выполняется делегирование;
- какие клиенты получают разные ответы;
- где хранятся журналы запросов;
- как проверяется распространение изменений;
- кто отвечает за аварийное восстановление.
Если используются разные DNS-продукты, полезно унифицировать процессы вокруг них: применять инфраструктуру как код, обязательное согласование изменений, автоматические проверки конфликтов и регулярную инвентаризацию зон.
Наиболее распространённые отказы
Одна из типичных причин аварий - неправильный DNS-сервер на клиенте. Устройство после обновления, подключения к VPN или смены сетевого профиля начинает обращаться не к корпоративному резолверу, а к шлюзу провайдера.
Другая проблема - чрезмерно большой TTL. Он уменьшает нагрузку, но усложняет миграции: старый адрес продолжает использоваться даже после исправления записи.
Опасны и слишком короткие значения TTL. Они увеличивают количество запросов, нагрузку на инфраструктуру и зависимость от доступности резолвера.
Отдельный класс ошибок связан с неявными зонами: похожие имена создаются в нескольких системах, а административные команды не знают, какая запись имеет приоритет. Наконец, часто отсутствует контроль удаления. После вывода сервера из эксплуатации старое имя остаётся в одной из зон и продолжает направлять часть трафика на несуществующий узел.
Что необходимо измерять
Минимальный набор показателей должен включать доступность резолверов, задержку ответа, долю ошибок и количество запросов к каждой зоне. Полезно отдельно отслеживать ответы `NXDOMAIN`, тайм-ауты, отказы по политике и обращения к устаревшим адресам.
Для критичных имён стоит выполнять синтетические проверки из разных сегментов: из офиса, VPN, облака, филиала и внешней сети. Один тест с рабочей станции не покажет, что пользователи другой группы получают иной ответ.
Также важно сохранять историю изменений записей и связывать её с заявками, коммитами инфраструктурного кода или событиями автоматизации. Если невозможно установить, кто и когда изменил адрес, диагностика будет превращаться в поиск по журналам разных систем.
Практический порядок внедрения
Начинать следует с инвентаризации: перечислить зоны, резолверы, делегирования, источники записей и группы клиентов. Затем необходимо выделить критичные имена и проверить, одинаково ли они разрешаются из всех нужных сегментов.
После этого можно формализовать views и политики, настроить централизованное журналирование, добавить автоматические проверки и только потом оптимизировать TTL или переносить зоны между платформами.
DNS редко ломается внезапно. Обычно аварии предшествуют небольшие расхождения: запись существует в двух местах, ответ отличается в филиале, старый сервер не удалён из зоны, а изменения выполняются без единого журнала. Если рассматривать DNS как контур управления, такие сигналы становятся видимыми заранее.
Внутренний DNS - это не вспомогательная служба, которую вспоминают только после сбоя. Он определяет, какие сервисы видит пользователь, куда направляется запрос и какие правила применяются ещё до установления соединения. Поэтому его надёжность зависит не только от доступности серверов, но и от качества моделей зон, представлений, политик и процессов изменений.