DNS-сервер для белых списков: как устроена фильтрация и что выбрать

Что такое белые списки DNS и зачем они нужны

Белый список DNS — это механизм фильтрации, при котором разрешены только заранее одобренные домены или IP-адреса, а всё остальное блокируется. В отличие от чёрных списков, где запрещён конкретный перечень ресурсов, белый список работает по принципу «запрещено всё, что явно не разрешено». Такой подход применяется в корпоративных сетях для ограничения доступа сотрудников, в государственных системах для контроля интернет-трафика и в домашних роутерах для родительского контроля.

Основное преимущество белых списков — предсказуемость: администратор точно знает, какие ресурсы доступны. Однако у этого подхода есть серьёзный недостаток — высокая вероятность ложных блокировок. Если в список не попал легитимный домен, пользователь не сможет открыть нужный сайт или сервис. Поэтому при проектировании DNS-фильтрации на основе белых списков важно тщательно продумывать структуру списка и механизмы его обновления.

В контексте DNS белый список может применяться на разных уровнях: на уровне резолвера (например, CoreDNS или Unbound), на уровне прокси-сервера или на уровне межсетевого экрана. В каждом случае принцип одинаков: DNS-запрос проверяется по списку разрешённых доменов, и если домен отсутствует, возвращается ответ NXDOMAIN или запрос перенаправляется на заглушку.

Как работает DNS-фильтрация с белыми списками

Когда пользователь вводит адрес сайта, его устройство отправляет DNS-запрос резолверу. В случае белого списка резолвер сверяет запрошенное доменное имя со списком разрешённых. Если домен есть в списке, резолвер выполняет обычное разрешение и возвращает IP-адрес. Если домена нет, резолвер может вернуть NXDOMAIN (домен не существует), перенаправить на специальную страницу-заглушку или просто не отвечать.

В более сложных архитектурах фильтрация может происходить на нескольких уровнях. Например, на уровне L3 (сетевой уровень) проверяется IP-адрес назначения — если он не входит в разрешённый диапазон CIDR, пакет отбрасывается ещё до обращения к DNS. На уровне L7 (прикладной уровень) DPI-система анализирует SNI в TLS-запросе и может разорвать соединение, даже если IP-адрес разрешён. Такая комбинированная фильтрация используется в государственных системах, например, в ТСПУ.

Для DNS-сервера с белыми списками важно уметь обрабатывать большие объёмы правил. При использовании простого списка ACL производительность может резко упасть при добавлении десятков тысяч доменов. Поэтому применяются структуры данных, такие как Bloom filter или trie, которые позволяют быстро проверять принадлежность домена к списку даже при миллионах записей.

Отличия белых списков от чёрных: когда что выбирать

Чёрные списки (blacklist) блокируют конкретные домены или IP-адреса, оставляя остальной интернет доступным. Это удобно для точечных ограничений, но требует постоянного обновления списка, так как заблокированные ресурсы могут менять адреса или использовать CDN. Белые списки, наоборот, обеспечивают максимальный контроль, но требуют тщательного подбора разрешённых ресурсов и могут вызывать недовольство пользователей из-за ограничений.

Выбор между этими подходами зависит от задач. Для корпоративной сети, где сотрудникам нужен доступ только к определённым сервисам (почта, CRM, внутренние порталы), белый список — оптимальное решение. Для домашнего использования или публичного Wi-Fi чаще применяют чёрные списки, чтобы блокировать вредоносные или нежелательные сайты, не ограничивая свободу пользователей.

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

Какие DNS-серверы поддерживают белые списки

Существует несколько DNS-серверов, которые можно настроить для работы с белыми списками. Один из самых популярных — CoreDNS, написанный на Go. Он поддерживает плагины, позволяющие реализовать фильтрацию по спискам доменов. Например, плагин acl может блокировать или разрешать запросы на основе IP-адресов клиентов или доменных имён. CoreDNS часто используется в Kubernetes и микросервисных архитектурах.

Другой вариант — Unbound, легковесный рекурсивный резолвер. Он поддерживает настройку локальных зон и может возвращать NXDOMAIN для доменов, не входящих в белый список. Unbound хорошо подходит для небольших сетей и встраиваемых устройств.

Также можно использовать PowerDNS с бэкендом, который хранит список разрешённых доменов, или Bind9 с настройкой зон. Для более сложных сценариев применяют связку DNS-сервера с внешним API-шлюзом, который проверяет домены по правилам Open Policy Agent (OPA). Такой подход позволяет динамически обновлять списки без перезапуска DNS-сервера.

Настройка собственного DNS-сервера с белым списком на CoreDNS

Рассмотрим пример настройки CoreDNS для фильтрации по белому списку. Допустим, мы хотим разрешить доступ только к доменам example.com и example.org. Для этого создадим файл Corefile с конфигурацией:

.:53 {
    acl {
        allow net 192.168.1.0/24
        allow domain example.com example.org
        drop
    }
    forward . 8.8.8.8
}

В этой конфигурации плагин acl разрешает запросы только для указанных доменов, а все остальные запросы отбрасываются (drop). Обратите внимание, что drop возвращает пустой ответ, что может привести к таймауту на стороне клиента. Лучше использовать reject, чтобы вернуть NXDOMAIN.

Для более гибкого управления можно использовать внешний файл со списком доменов и подключать его через плагин file или hosts. Например, создать файл whitelist.db в формате зоны и указать его в Corefile. Это упрощает обновление списка без изменения конфигурации.

Важно помнить, что CoreDNS не выполняет рекурсивное разрешение самостоятельно, поэтому для получения IP-адресов разрешённых доменов необходимо настроить форвардинг на вышестоящий DNS-сервер, как показано в примере (forward . 8.8.8.8).

Использование Open Policy Agent для динамических белых списков

Open Policy Agent (OPA) — это движок политик с открытым исходным кодом, который позволяет проверять запросы по правилам, написанным на языке Rego. В контексте DNS-фильтрации OPA может выступать в роли внешнего сервиса, который принимает DNS-запросы и возвращает решение — разрешить или заблокировать домен.

Архитектура выглядит так: DNS-сервер (например, CoreDNS) получает запрос, отправляет его в OPA через API, OPA проверяет домен по правилам белого списка и возвращает ответ. Если домен разрешён, DNS-сервер выполняет обычное разрешение; если нет — возвращает NXDOMAIN.

Пример правила Rego для белого списка:

package dns

whitelist = {"example.com", "example.org"}

default allow = false

allow {
    input.domain in whitelist
}

Этот подход позволяет централизованно управлять политиками, быстро обновлять списки и вести аудит запросов. OPA также поддерживает кэширование решений, что снижает нагрузку на DNS-сервер. Однако добавление внешнего сервиса увеличивает задержку, поэтому для высоконагруженных систем необходимо тщательно настраивать кэширование и оптимизировать производительность.

Метрики и тестирование DNS-фильтрации с белыми списками

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

• Latency (задержка) — время ответа DNS-сервера. Измеряется в p50, p95, p99 перцентилях. Высокая задержка может быть вызвана большим количеством правил или обращением к внешнему API.
• False positive rate (ложные блокировки) — процент легитимных доменов, которые были заблокированы по ошибке. Этот показатель критичен для белых списков, так как даже небольшая ошибка может сделать недоступным важный сервис.
• Throughput (пропускная способность) — количество запросов в секунду, которое выдерживает DNS-сервер. При добавлении тысяч правил производительность может снизиться.

Для тестирования можно использовать инструменты нагрузочного тестирования, такие как dnsperf или wrk2. Например, сценарий «массовое добавление 10 000 доменов в белый список» позволит оценить, как изменяется latency и throughput. Также полезно настроить трассировку запросов с помощью OpenTelemetry, чтобы выявить узкие места в цепочке обработки.

При проектировании системы стоит закладывать запас по производительности, чтобы фильтрация не становилась узким местом. Использование Bloom filter или trie для хранения списка доменов позволяет значительно ускорить проверку.

Практические примеры: корпоративный DNS с белым списком

Рассмотрим пример корпоративной сети, где требуется ограничить доступ сотрудников только к разрешённым ресурсам. Для этого можно развернуть DNS-сервер на базе CoreDNS с белым списком, содержащим домены корпоративной почты, CRM-системы и внутренних порталов.

Конфигурация может выглядеть так:

.:53 {
    acl {
        allow net 10.0.0.0/8
        allow domain mail.company.com crm.company.com portal.company.com
        reject
    }
    forward . 10.0.0.1
}

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

Важно предусмотреть возможность временного добавления доменов для новых сервисов. Для этого можно использовать отдельный файл с дополнительными правилами или API для динамического обновления. Также стоит настроить логирование всех заблокированных запросов, чтобы анализировать, какие ресурсы пытаются использовать сотрудники, и при необходимости расширять белый список.

Ограничения и риски использования белых списков DNS

Белые списки DNS имеют ряд ограничений, которые важно учитывать.

Во-первых, они не защищают от обхода фильтрации. Пользователи могут использовать VPN, прокси-серверы или альтернативные DNS-резолверы (например, DoH), чтобы обойти ограничения. Поэтому для надёжной фильтрации необходимо комбинировать DNS-фильтрацию с сетевыми блокировками на уровне IP и DPI.

Во-вторых, белые списки могут создавать проблемы с доступом к легитимным сервисам, которые используют динамические домены или CDN. Например, если сайт использует несколько поддоменов для разных регионов, их все нужно включать в список. Это увеличивает объём списка и риск ошибок.

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

Наконец, белые списки требуют постоянного обновления. Новые сервисы появляются, старые меняют домены, и если список не обновлять, пользователи потеряют доступ к нужным ресурсам. Автоматизация обновления списков — обязательное условие для поддержания работоспособности системы.

Заключение: как выбрать DNS-сервер для белых списков

Выбор DNS-сервера для белых списков зависит от масштаба сети, требований к производительности и сложности управления. Для небольших сетей подойдут лёгкие решения, такие как Unbound или dnsmasq. Для корпоративных сред с большим количеством правил лучше использовать CoreDNS с плагинами или связку с OPA.

При выборе стоит учитывать:

• Производительность — способность обрабатывать большое количество запросов и правил без существенной задержки.
• Гибкость — возможность динамического обновления списков без перезапуска сервера.
• Интеграция — совместимость с существующей инфраструктурой и инструментами мониторинга.
• Безопасность — поддержка DNSSEC, DoH/DoT для защиты от подмены DNS-ответов.

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

Вопросы и ответы

.:53 {
    acl {
        allow domain example.com
        reject
    }
    forward . 8.8.8.8
}