Фильтрация запросов на уровне DNS

Начиная с версии 9.8.1 DNS-сервера bind появилась новая возможность — DNS RPZ.

Что это за зверь и с чем его едят?

Аббревиатура RPZ означает response policy zone — зона с политикой ответов. Это технология, разработанная ISC, которая предоставляет операторам связи простой способ блокирования DNS-запросов к некоторым ресурсам или перенаправления их на альтернативный адрес. RPZ — это зона, которая может передаваться между серверами (DNS AXFR/IXFR), защищена подписями транзакций (DNS TSIG) и обновляется в режиме реального времени (DNS NOTIFY).

Формат зоны

Как и для любой другой DNS-зоны, требуется SOA-запись и, как минимум, одна NS-запись. SOA — действительная, имеющая серийный номер и таймеры запись, используемая для делегирования зоны и указывающая времени жизни записей (TTL). NS-запись никогда не используется и служит для совместимости. Обычно, единственная NS-запись имеет фиктивное значение localhost. Остальная часть зоны — это выражения для DNS-политик. Политики могут применяться к именам доменов или к их шаблонам.

Как работает

Упрощенно работу RPZ можно представить следующей схемой:

В правой части показана схема работы с обычным кеширующим DNS-сервером, который возвращает клиенту все ответы от коневых серверов, как есть. В случае с RPZ появляется Security Policy Provider (провайдер политик безопасности) — DNS-сервер с которого мы берем политики разрешения доменных имен. Наличие стороннего провайдера совершенно не обязательно, мы можем сами задать свои локальные политики. Об этом чуть позже, в примерe.

Провайдеров может быть несколько, в том числе мы можем создать свой собственный сервер RPZ:

Более подробно о работе протокола можно прочитать в официальной документации (ссылки ниже) — думаю, те, кому нужны детали, осилят ее самостоятельно.

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

Сперва в файле /etc/bind/named.conf.options опцией «response-policy» включаем RPZ:

Внутри «response-policy» зон может быть несколько, причем у каждой может быть своя политика (подробности см. в спецификации).

В файле /etc/bind/named.conf.local помещаем описание зоны:

И, наконец, сама зона (файл /etc/bind/db.rpz.zone):

Применяем новые настройки:

и смотрим, что у нас вышло:

Как видно из ответа сервера, адрес подменен на habrahabr.ru. В браузере увидим следующее:

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

Здесь запрос остался без ответа. То же самое произойдет с любым поддоменом gov.by:

Нетрудно догадаться, что все субдомены домена blabla.com будут подменены на адрес 1.2.3.4, а все домены зоны xxx будут заменены на localhost.

Последнюю строчку зоны поясню отдельно. Являясь мелким провайдером в провинциальном городке, часто сталкиваемся с проблемой совершенно тугих юзеров, для которых набрать адрес нашей домашней странички является непосильной задачей (а это отправная точка для всех наших внутренних ресурсов). Дело порой доходит до комических случаев, когда техподдержка бьется в истерике головой об стол. Именно для этого была создана эта запись. Клиенту достаточно набрать в адресной строке браузера «1.by» (без кавычек), и он попадает туда, куда нужно:

А чтобы подобное безобразие не мозолило глаз более-менее грамотным пользователям, средствами веб-сервера (RewriteRule в Apache) хост «1.by» перенаправляется на валидный адрес сервера.

https://habr.com/ru/post/177649/