Настройка Split DNS: практическое руководство по разделению внутреннего и внешнего DNS-трафика

Split DNS - это метод, при котором один и тот же домен разрешается в разные IP-адреса в зависимости от источника запроса. Для внутренних пользователей имя wiki.corp.local указывает на приватный сервер в локальной сети, а для внешних - на публичный адрес или возвращает ошибку. Это решает ключевые проблемы безопасности и гибкости инфраструктуры. Данное руководство содержит проверенные пошаговые конфигурации для BIND9, Unbound и PowerDNS, которые можно скопировать и адаптировать для своей среды, экономя часы на поиск и отладку.

Что такое Split DNS и зачем он нужен в корпоративной инфраструктуре

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

Типичные проблемы, которые решает разделенный DNS

Уязвимость внутренних ресурсов. Публикация записей типа db.corp.local в публичную DNS-зону раскрывает топологию сети и создает точку для атаки.
Сложности с доступом к корпоративным сервисам. Сотрудник в офисе должен быстро получить доступ к внутреннему GitLab, а при работе из дома через VPN - к его публичному интерфейсу. Без Split DNS это требует ручного переключения настроек или использования разных доменов.
Невозможность безопасного тестирования. Изменения в DNS-записях для production среды нельзя проверить без риска сломать работу для всех пользователей.
Риск DNS-фильтрации и блокировок. Внешние запросы к внутренним доменам могут попадать в черные списки провайдеров или возвращать неожиданные результаты.

Конкретные сценарии применения Split DNS включают организацию безопасного доступа к внутренним серверам через VPN, когда внутренние пользователи получают приватный IP, а внешние видят ошибку или публичный адрес. Другой сценарий - создание изолированных тестовых сред, где dev.company.com указывает на тестовый сервер для разработчиков в отдельном VLAN и на боевой для всех остальных. Этот подход схож с настройкой IntranetZone для SSO, описанной в контексте настройки Kerberos, но реализуется на сетевом, DNS-уровне.

Выбор инструмента: BIND9, Unbound или PowerDNS для реализации Split DNS

Выбор ПО зависит от опыта команды, существующей инфраструктуры и конкретных требований к гибкости и производительности. Вот краткое сравнение, основанное на практическом опыте внедрения.

BIND9. Классический авторитативный и рекурсивный сервер. Предоставляет максимальную гибкость через механизм view. Подходит для сложных сценариев с множеством правил разделения трафика (например, отдельные view для офиса, VPN и облака). Конфигурация сложнее, требует внимания к синтаксису и порядку объявления view.
Unbound. Рекурсивный резолвер, ориентированный на безопасность и производительность. Реализация Split DNS через local-zone и local-data проще, чем views в BIND. Часто используется в паре с авторитативным сервером (например, PowerDNS) для разделения функций. Идеален для типовых задач разделения трафика между внутренней сетью и интернетом.
PowerDNS. Авторитативный сервер с сильной интеграцией с бэкенд-базами данных (PostgreSQL, MySQL). Удобен для динамических сред, где записи часто обновляются через API. Реализация Split DNS возможна через разные бэкенды или скрипты, что требует более глубокой настройки.

Рекомендация: используйте BIND9 для сложных корпоративных сценариев с множеством view. Выберите Unbound для более простых задач разделения трафика или если в инфраструктуре уже используется этот резолвер для кэширования. Если вам интересны альтернативные методы управления DNS-трафиком, например, на основе географии, изучите наше практическое руководство по геофильтрации DNS.

Готовая конфигурация Split DNS в BIND9 с использованием View и ACL

Это пошаговая инструкция с готовыми фрагментами для файла named.conf. Основные элементы: Access Control List (ACL) для определения источников запросов и секции view для предоставления разных ответов.

Настройка ACL для точного разделения сетевого трафика

ACL определяет, откуда пришел запрос. Ошибка в ACL приведет к тому, что внутренние пользователи получат внешние ответы и наоборот. Определите все диапазоны внутренних IP-адресов, включая IPv6.

acl "internal-nets" {
    10.0.0.0/8;
    192.168.0.0/16;
    172.16.0.0/12;
    ::1/128;
    fe80::/10;
};

acl "vpn-nets" {
    10.8.0.0/24; // Пул адресов VPN (например, WireGuard)
};

acl "trusted" {
    "internal-nets";
    "vpn-nets";
    // Можно добавить IP облачных сред
};

Убедитесь, что в ACL trusted учтены все источники внутренних запросов: рабочие станции, серверы, VPN-клиенты.

Создание и настройка view: internal для своих, external для всех остальных

Секция view содержит логику ответа для определенной группы клиентов (match-clients). Порядок объявления view критически важен: BIND использует первый подходящий view, поэтому более специфичный (например, для VPN) должен быть объявлен раньше общего.

view "internal" {
    // Этот view отвечает запросам из доверенных сетей
    match-clients { trusted; };
    recursion yes;
    allow-query { trusted; };

    // Внутренняя зона с приватными записями
    zone "corp.local" IN {
        type master;
        file "/etc/bind/zones/db.corp.local.internal";
        allow-query { any; };
    };

    // Рекурсивный резолвинг для всех остальных запросов
    zone "." IN {
        type hint;
        file "/etc/bind/db.root";
    };
};

view "external" {
    // Этот view отвечает на все остальные запросы
    match-clients { any; };
    recursion no; // Без рекурсии для безопасности
    allow-query { any; };

    // Та же зона, но с публичными записями или NXDOMAIN
    zone "corp.local" IN {
        type master;
        file "/etc/bind/zones/db.corp.local.external";
        allow-query { any; };
    };
};

Файл db.corp.local.internal содержит записи с приватными IP (например, wiki IN A 10.0.1.5). Файл db.corp.local.external может содержать записи с публичными адресами или быть пустым, что приведет к ответу NXDOMAIN (несуществующая зона) на внешние запросы к corp.local. Для интеграции подобной DNS-инфраструктуры в смешанные среды с Windows и Linux пригодится наше руководство по DNS-маршрутизации.

Настройка Split DNS в Unbound: более легкий путь для рекурсивного резолвинга

Unbound работает как кэширующий рекурсивный резолвер. Split DNS реализуется через директивы local-zone и local-data в файле unbound.conf.

server:
    # ... другие настройки server ...

    # Определяем приватную зону как static
    local-zone: "corp.local" static

    # Приватные записи для внутренних IP
    local-data: "wiki.corp.local. IN A 10.0.1.5"
    local-data: "git.corp.local. IN A 10.0.1.6"

    # Контроль доступа: разрешаем запросы из внутренних сетей
    access-control:102.168.1.0/24 allow
    access-control:10.8.0.0/24 allow  # VPN сеть

    # Для внешних запросов к corp.local можно настроить форвардинг
    # или просто не давать ответ (по умолчанию для static зоны - NXDOMAIN)
    # forward-zone:
    #     name: "corp.local"
    #     forward-addr: 8.8.8.8  # Пример форвардинга внешним DNS

В этой конфигурации запрос к wiki.corp.local с IP из диапазона 192.168.1.0/24 или 10.8.0.0/24 получит ответ 10.0.1.5. Запрос из любого другого источника (например, из интернета) получит ответ NXDOMAIN или будет перенаправлен на внешний DNS-сервер, если раскомментирован блок forward-zone. Этот подход проще views BIND, но менее гибок для сложных сценариев с множеством групп пользователей.

Практический сценарий: безопасный доступ к внутренним ресурсам через VPN

Без Split DNS пользователь, подключившись по VPN к офису, может продолжать резолвить внутренние имена типа wiki.corp.local через публичный DNS своего домашнего провайдера и получать ошибку. Решение - связка VPN (например, WireGuard) и DNS-сервера с настроенным Split DNS.

На VPN-сервере в конфигурации клиента (/etc/wireguard/wg0.conf для интерфейса) пропишите внутренний DNS-сервер: DNS = 10.0.1.2.
На DNS-сервере (BIND9 или Unbound) в ACL или access-control добавьте подсеть VPN, например, 10.8.0.0/24.
В результате запрос к internal.corp.local с IP из диапазона VPN получит приватный ответ, а все остальные запросы пользователя будут обрабатываться стандартно через рекурсивный резолвер.

Это обеспечивает бесшовный доступ: сотрудник заходит в VPN и получает корректные IP внутренних сервисов, не замечая переключения. Для комплексной защиты такого трафика от прослушивания рассмотрите внедрение DNS-over-TLS. Готовые конфигурации можно найти в нашем руководстве по безопасной DNS-маршрутизации.

Интеграция с WireGuard: как передать клиенту правильный DNS-сервер

Ключевой параметр - DNS в секции [Interface] конфигурационного файла клиента WireGuard.

[Interface]
PrivateKey = [CLIENT_PRIVATE_KEY]
Address = 10.8.0.2/24
DNS = 10.0.1.2  # IP DNS-сервера с Split DNS

[Peer]
PublicKey = [SERVER_PUBLIC_KEY]
Endpoint = vpn.company.com:51820
AllowedIPs = 0.0.0.0/0, ::/0  # Маршрутизация всего трафика через туннель

Параметр AllowedIPs = 0.0.0.0/0 гарантирует, что DNS-запросы тоже пойдут через туннель к указанному серверу 10.0.1.2, а не к DNS провайдера. Это критически важно для работы схемы. Если вам требуется настроить сам VPN-сервер с нуля, обратитесь к базовым инструкциям в практическом руководстве по Linux.

Создание изолированной тестовой среды с помощью Split DNS

Сценарий: разработчики работают в тестовой сети (VLAN 20, подсеть 192.168.20.0/24), а все остальные сотрудники - в рабочей (VLAN 10, подсеть 192.168.10.0/24). Задача: чтобы имя app.company.com для разработчиков резолвилось в тестовый сервер (192.168.20.10), а для всех остальных - в боевой (93.184.216.34).

В BIND9 это реализуется добавлением третьего view:

acl "dev-nets" { 192.168.20.0/24; };

view "staging" {
    match-clients { dev-nets; };
    recursion yes;
    allow-query { dev-nets; };

    zone "company.com" IN {
        type master;
        file "/etc/bind/zones/db.company.com.staging"; // Записи на тестовые IP
    };
};

view "internal" {
    match-clients { internal-nets; };
    # ... остальная конфигурация prod-зоны company.com ...
};

view "external" {
    match-clients { any; };
    # ... конфигурация внешней зоны company.com ...
};

Порядок view должен быть: staging, internal, external. Запрос от IP 192.168.20.5 попадет в view "staging" и получит тестовый IP для app.company.com. Запрос от IP 192.168.10.5 попадет в view "internal" и получит боевой IP. Это позволяет безопасно тестировать изменения в изолированной среде, не затрагивая основную инфраструктуру.

Верификация, отладка и частые ошибки при настройке Split DNS

После настройки проверьте работу с разных точек сети. Используйте dig, указывая конкретный DNS-сервер.

Проверка из внутренней сети:
dig @10.0.1.2 wiki.corp.local
Ожидаемый ответ: ANSWER SECTION с приватным IP (например, 10.0.1.5).
Проверка из внешней сети (эмуляция):
dig @93.184.216.34 wiki.corp.local
Ожидаемый ответ: NXDOMAIN или публичный IP, но не приватный 10.0.1.5.
Анализ логов BIND:
Включите логирование запросов: rndc querylog on. В логах (/var/log/named/queries.log) будет указано, из какого view пришел ответ.

Типичные ошибки:

Неправильный порядок view. BIND проверяет view сверху вниз. View с match-clients { any; }; должен быть последним.
Некорректные или неполные ACL. Если IP VPN-клиентов не добавлен в доверенные ACL, они попадут во внешний view.
Забытые зоны в каком-либо view. Зона должна быть объявлена во всех view, где планируется давать на нее ответ. Иначе в некоторых view запросы к ней будут делегироваться корневым серверам.
Проблемы с рекурсией. Если во внешнем view оставлена recursion yes;, это может сделать сервер уязвимым для амплификации DNS-атак.

Для проверки отсутствия утечки информации выполните запрос к внутреннему имени из внешней сети. Ответ должен быть ожидаемым (публичный адрес или NXDOMAIN), но ни в коем случае не приватным IP. Если вы столкнулись с проблемами производительности DNS после внедрения, возможно, потребуется оптимизировать кэширование. Методы описаны в руководстве по оптимизации DNS-кэширования.

Для автоматизации управления DNS-записями в таких динамических средах рассмотрите использование инструментов Infrastructure as Code. Сервисы вроде AiTunnel могут помочь в автоматизации смежных задач, агрегируя API различных ИИ-моделей для генерации конфигураций или скриптов, хотя прямое управление DNS не является их основной функцией.