Как настроить доверенные DNS серверы

Угрозы при использовании неподконтрольных DNS

Если устройство использует DNS-сервер, который не контролируется администратором (например, провайдерский по умолчанию, публичный Google DNS или Cloudflare), возникают конкретные уязвимости:

• Подмена ответа (DNS Spoofing/Pharming): Злоумышленник может перенаправить запрос к bank.example.com на IP-адрес своего сервера с точной копией сайта для кражи учётных данных.
• Утечка структуры сети: Запросы к внутренним, непубличным доменам (вроде erp.corp.local) уходят в интернет, раскрывая названия критичных систем.
• Обход корпоративных фильтров: Современные протоколы, такие как DNS-over-HTTPS (DoH), инкапсулируют DNS-запросы в обычный HTTPS-трафик. Это позволяет клиентам использовать любой сторонний DNS, полностью игнорируя корпоративные политики и системы блокировки нежелательных ресурсов.
• Наблюдение за активностью: Сторонний оператор DNS получает полный журнал всех интернет-запросов от устройств организации, что является утечкой чувствительной мета-информации.

Внутренний корпоративный DNS-сервер

Развёртывание собственного DNS-резолвера (например, на базе BIND, Unbound, PowerDNS или Windows Server DNS) — стратегический выбор для организаций с требованиями ФСТЭК или 152-ФЗ. Ключевая технология здесь — Response Policy Zones (RPZ), позволяющая гибко управлять политиками ответов.

Преимущества:

• Полный суверенитет: внутренние домены никогда не покидают сеть.
• Гибкая фильтрация: возможность мгновенно добавлять домены в чёрный или белый список по внутренним регламентам, не завися от обновлений публичных баз.
• Интеграция с SIEM/SOC: все логи запросов остаются внутри периметра и могут анализироваться на предмет аномалий.
• Высокая производительность за счёт кэширования.

Публичные DNS с функциями фильтрации

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

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

Рекомендуемая архитектура

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

1. Клиентские устройства настраиваются на один или два внутренних кэширующих DNS-сервера.
2. Эти внутренние серверы выполняют фильтрацию (RPZ), резолвинг внутренних зон и кэширование.
3. Для запросов в интернет внутренние серверы используют настроенные внешние доверенные резолверы (например, Яндекс.DNS) или рекурсивно обращаются к корневым серверам.

Такая архитектура даёт единую точку для применения политик, логирования и скрытия всей внутренней DNS-активности от внешнего мира.

Windows: групповые политики (GPO)

В среде Active Directory это самый действенный метод. Создайте или отредактируйте объект групповой политики (GPO), связанный с нужными подразделениями.

Путь в редакторе управления групповыми политиками: Конфигурация компьютера -> Политики -> Административные шаблоны -> Сеть -> DNS-клиент.

Критически важные параметры:

• «Настройка DNS-серверов»: Включить и указать IP-адреса ваших доверенных серверов через запятую.
• «Выключить разрешение имен для многоадресных рассылок с несколькими шлюзами»: Включить. Эта функция (smart multi-homed name resolution) может заставлять Windows использовать DNS от альтернативного сетевого интерфейса (например, VPN), что нарушает единую политику.
• «Настройка DNS через HTTPS (DoH)»: Отключить, если не планируется централизованное развёртывание DoH с контролем. Это предотвратит использование клиентами сторонних DoH-резолверов.

Linux (systemd-based дистрибутивы)

В современных дистрибутивах (RHEL 8+, Ubuntu 18.04+, Fedora) за разрешение имён часто отвечает systemd-resolved. Конфигурация задаётся в файле /etc/systemd/resolved.conf.

[Resolve]
DNS=192.168.1.10 192.168.1.11  # Основные доверенные DNS
FallbackDNS=77.88.8.8 1.0.0.2   # Резервные на случай недоступности основных
Domains=~.                      # Применять эти настройки ко всем доменам
DNSOverTLS=opportunistic        # Использовать DoT, если сервер его поддерживает
DNSSEC=allow-downgrade         # Опционально: проверка подлинности ответов
Cache=yes

После изменения конфигурации выполните: sudo systemctl restart systemd-resolved. Для старых дистрибутивов или сетей, управляемых через NetworkManager, настройка DNS производится в конфигурационных файлах конкретного подключения (в /etc/sysconfig/network-scripts/ или через nmcli).

Мобильные устройства (Android / iOS)

Без использования систем управления мобильными устройствами (MDM) обеспечить принудительную настройку DNS практически невозможно. Пользователь может легко переключиться на DoH в браузере или в настройках приватности.

В рамках MDM (например, Miradore, MDM от VK, профили для Apple Business Manager) можно развернуть профили конфигурации:

• Android (рабочий профиль): В политиках ограничений можно задать режим Private DNS и указать хост (dns.yourcompany.local или доверенный публичный).
• iOS/iPadOS: В профиле конфигурации используется раздел «Настройки DNS». Ключевой параметр — SupplementalMatchDomains со значением . (точка), что означает «применять эти DNS-серверы для всех доменов без исключений».

Сетевой уровень: DHCP и брандмауэр

Это «последний рубеж» для устройств, не управляемых централизованно: оборудование IoT, гостевой Wi-Fi, личные ноутбуки.

• DHCP-сервер: В опции 006 (DNS Servers) укажите адреса доверенных DNS-серверов. Все устройства, получающие адрес автоматически, будут использовать их.

  # Пример для ISC DHCP (Linux)
  option domain-name-servers 192.168.1.10, 192.168.1.11;

• Периметровый брандмауэр: Создайте правило, блокирующее исходящие DNS-запросы (UDP и TCP порт 53, TCP порт 853 для DoT) на любые IP-адреса, кроме разрешённого списка (ваши внутренние и доверенные внешние DNS-серверы). Это предотвратит любые попытки устройств в обход использовать другие резолверы.