Настройка представлений (View) в BIND9

Настройка представлений в BIND9 может пригодиться в тех случаях, когда требуется гибко управлять разрешением имен для клиентов из разных подсетей. Это особенно актуально в конфигурациях Split DNS, а отсутствие подобного функционала в Windows ставит BIND9 в ещё более выгодное положение.

Начиная с Windows 2016 есть возможность управлять ответами сервера в зависимости от подсети клиента, скажете вы. Действительно, но в Windows этот функционал очень сырой и крайне неудобный в использовании.


Если вам интересно подробнее изучить задачи администрирования BIND9, рекомендую обратиться к соответствующему тегу на моем блоге.


Настройка представлений в BIND9

Помимо использования представлений BIND9 для реализации Split DNS, есть также некоторые другие случаи, когда этот функционал будет крайне полезным. Например в зависимости от расположения клиента — гостевая или корпоративная сеть — вы можете гибко управлять перенаправлениями запросов к разным серверам, не позволяя «чужим» устройствам ломиться к внутренним DNS.

Предварительная настройка

На данном этапе я предполагаю, что у вас уже есть настроенный и работающий сервер BIND9. Если вдруг нет, то предлагаю прочитать мою предыдущую статью — Сервер пересылки на BIND9. Именно на её основе я и буду настраивать представления.

Также помните, что одновременно использовать директивы zone и view на одном уровне нельзя, вы столкнетесь с подобными ошибками:

Если вы твердо решили иметь дела с представлениями, то директива zone должна появляться только внутри view. Собственно именно поэтому нужно исключить из named.conf вложенный конфиг, который мы добавляли в предыдущей статье. Полная строчка выглядит так:

Закомментируйте её и можно приступать к настройке представлений.

Базовая конфигурация

В базовом виде нам достаточно настроить списки доступа и отдельное представление (или несколько) с нужными записями. Списки доступа (acl) можно вполне взять в готовом виде из предыдущей статьи. Речь идет о файле /etc/bind/named.conf.acl и его содержимом:

Не забывайте, что этот файл должен быть подключен в основной конфиг /etc/bind/named.conf с помощью строчки:

Итак, для настройки представлений мы открываем новый файл:

Он будет содержать список представлений (для начала только два). Вставляем в него содержимое:

Примечание: это базовый вид представлений. На самом деле объект View включает достаточно много разных опций 1, которые, тем не менее, по умолчанию уже имеют подходящее для нас значение. За исключением, правда, опции allow-transfer (и может чего ещё…), которая по умолчанию разрешает передачу зоны любому другому хосту.

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

Ну а теперь создаем файлы зон 2 (сначала для представления local). Откроем для редактирования:

Вставляем содержимое:

Примечание: обратите внимание, что записи внутри зоны могут быть определены по-разному — они могут быть полностью или не полностью квалифицированными. Если запись в конце имеет точку 3, то она называется полностью квалифицированной. В противном случае запись не полностью квалифицирована и в конце к ней будет добавлено значение, которое определено в переменной $ORIGIN 4, либо имя файла зоны (такое поведение может быть нежелательным, именно поэтому важно явно устанавливать значение $ORIGIN). Кстати, смысл «собачки» — @ — внутри файла зоны у определенных записей ни что иное, как ссылка на значение переменной $ORIGIN. Вот так-то.

Теперь открываем для редактирования файл представления dmz:

Вот его содержимое:

Примечание: некоторые вопросы могут вызвать размышления над оптимальным значением поля serial внутри записи SOA. Одним из возможных подходов является установка даты с добавлением индекса (на случай, если внутри дня зону придется менять несколько раз) в формате YYYYMMDDxx 5. Индексом xx может также служить отметка времени или что-то другое. Тем не менее в нашем случае это все не имеет большого значения — зону мы никому не передаем.

Подключаем дополнительный конфиг named.conf.local в основной — /etc/bind/named.conf:

Подгружаем новую конфигурацию:

Если вдруг имена разрешаются неправильно или не разрешаются вообще, то в логах можно посмотреть ошибки подгружения конфигов командой:

Например можете увидеть что-то подобное:

Если ошибок у вас нет, самое время проверить как все работает.

Проверка

Итак, с любого клиента в подсети dmz (у меня это 172.16.0.0/12, как и определено в файле named.conf.acl) выполним ряд запросов и убедимся, что сервер отдает именно то, что мы ожидаем:

Где 192.168.1.14 — напоминаю, адрес вашего бинда. Если у вас все ещё нет утилиты dig, поставим её командой:

Примечание: можно также воспользоваться всем знакомой кроссплатформенной утилитой nslookup. Либо используйте командлет Resolve-DnsName, если у вас только Windows-клиенты. Инструмент не так важен, ответы сервера во всех случаях должны совпадать.

Теперь смотрим что возвращается клиентам в подсети local:

Как видно, адреса отличаются, а значит все работает как мы и хотели.

Расширенная конфигурация

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

После любого изменения не забывайте подгружать конфигурацию с помощью rndc.

Зоны обратного просмотра

Например вот так может выглядеть файл named.conf.local с секцией обратной зоны внутри представления local (на местах многоточия часть конфигурации пропущена для наглядности):

Сам файл 0.168.192.IN-ADDR.ARPA может иметь приблизительно такой вид 6, основываясь на данных зоны bissquit.com, которую настраивали в предыдущих главах:

Проверь корректность разрешения записей можно командой:

Идем дальше.

Перенаправление запросов

Предположим, что все локальные зоны (*.local) в нашей воображаемой инфраструктуре хостит контроллер домена и запросы надо перенаправлять на него. Сделать это можно путем добавления дополнительной секции с типом зоны forward:

Для наглядности также пропускаю описанные ранее участки конфигурации.

Стандартные зоны

Есть ряд зон, которые обязательно должны присутствовать в конфигурации сервера имен согласно RFC 1912 7. Собственно эти зоны уже по умолчанию поставляются в BIND9. В основную конфигурацию они подключались файлом named.conf.default-zones, который мы закомментировали в самом начале статьи. Теперь пришло время вернуть дефолтные файлы зон обратно.

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

Файлы уже лежат в каталоге /etc/bind. Просто добавим в представления следующие куски конфигурации:

Готово.

Корневые подсказки

Осталось добавить в наши представления файл зоны со стандартным набором корневых серверов, который также поставляется по умолчанию:

Итого представление local внутри файл конфигурации named.conf.local примет следующий вид:

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

comments powered by HyperComments
1revised
2022-01-13 03:28:30
<strong>3college</strong>
free gay adult chat
2022-01-14 14:07:49
<strong>asain gay chat phone lines free https://bjsgaychatroom.info/</strong>
utah gay bi chat
2022-01-14 20:09:39
<strong>dirty gay video chat free https://gaytgpost.com/</strong>
gay phone chat
2022-01-14 23:30:43
<strong>in gay chat what is an poz? https://gay-buddies.com/</strong>
u.s. justice department gay dating app
2022-01-15 23:45:06
<strong>gay dating southwest florida https://speedgaydate.com/</strong>
Яндекс.Метрика