Настройка BIND 8.x и BIND 9.x для поддержки небольшого корпоративного домена
Во-первых, здесь мы будем иметь дело с файлом named.conf, который располагается по умолчанию либо в каталоге /etc (BIND 9.x), либо /etc/namedb (BIND 8.x). Во-вторых, формат директив этого файла конфигурации совершенно иной, чем в BIND 4.х.
Сначала рассмотрим сервер, который не поддерживает рекурсивных запросов, но обслуживает запросы к зоне своей ответственности:
options { directory "/etc/namedb"; allow-query {any;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; }; //Root server hints zone "." { type hint; file "named.root"; }; // Forward Loopback zone "localhost" { type master; file "localhost"; }; // Reverse Loopback zone "0.0.127.in-addr.arpa" { type master; file "localhosr.rev"; }; // Corporative domain zone "vega.ru" { type master; file "vega.ru"; allow-transfer { 194.226.65.3; }; }; // Reverse corporative domain zone "43.226.194.in-addr.arpa" { type master; file "43.226.194.in-addr.arpa"; allow-transfer { 194.226.65.3; }; };
Директива options задает опции, значение которых распространяется на все зоны, поддерживаемые данным сервером. Опция directory определяет место расположения файлов описания зон. Опция allow-query разрешает обслуживать запросы от всех клиентов Интернет. Такое значение в данном случае позволяет отвечать на запросы к зонам ответственности сервера. Опция recursion отменяет обслуживание любых рекурсивных запросов. Далее следуют опции имитации обслуживания инверсных запросов (fake-iquery), отмены поиска дополнительной информации для ответов рефералов (referrals, опция fetch-glue, в BIND 9.х не нужна, т.к. реализована по умолчанию), и опция противодействия спуфингу (use-id-pool в BIND 9.x не нужна, т.к. реализована по умолчанию).
Далее идет описание корневой зоны. Тип зоны указан как hint (буквально "подсказка"). Зона содержит информацию об именах и адресах серверов,обслуживающих корневую зону DNS.
За описанием корневой зоны следуют описания зон "петли" (localhost и 0.0.127.in-addr.arpa).
Сервер определен для этих зон как master зоны. Ни каких дополнительных опций в описании конфигурации этих зон нет.
За ними следует описание настроек named для управления корпоративной зоной (vega.ru). Здесь мы ограничили число хостов, которые могут копировать зону slave сервером зоны. Если необходимо, то здесь можно расположить и другие хосты, которым будет разрешено копировать зону из соображений разгрузки master сервера, например.
Последней указаны настройки named для работы с "обратной" корпоративной зоной. Эти настройки ничем не отличаются от настроек "прямой" зоны.
Теперь мы расширим функциональность нашего сервера и разрешим ему обслуживать рекурсивные запросы. Но только пусть эти запросы будут исходить из корпоративной сети. Если мы просто разрешим рекурсию в директиве options:
options { directory "/etc/namedb"; allow-query {any;}; recursion yes; fake-iquery yes; fetch-glue no; use-id-pool yes; };
то мы своей цели не добьемся. Сервер будет обрабатывать любые рекурсивные запросы, откуда бы они не исходили. В принципе для такого поведения вообще не нужно указывать опцию recursion. Рекурсия включается по умолчанию.
Для того, чтобы разрешить рекурсию только "своим" хостам, следует воспользоваться директивой allow-recursion:
options { directory "/etc/namedb"; allow-query {any;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; allow-reqursion { 194.226.43/24;}; };
В данном случае рекурсия разрешена только хостам из сети 194.226.43.0. Для всех остальных она запрещена опцией recursion.
Вообще говоря, из всех зон, которыми управляет наш сервер, для всего остального мира интересны только корпоративные зоны: прямая зона vega.ru и "обратная" зона 43.226.194.in-addr.arpa. Поэтому, если строго следовать назначению нашего сервера - обслуживать по максимуму корпоративную сеть и по необходимому минимуму весь остальной мир, мы должны несколько изменить настройки.
В первую очередь разделим весь мир на "своих" и "чужих".
Это делается при помощи директивы acl (access control list):
acl "vega-net" { 194.226.43/24; }; acl "vega-friend" { 194.226.65/24; }; options { directory "/etc/namedb"; allow-query {vega-net;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; };
Два списка контроля доступа содержат пулы адресов корпоративной сети и сети slave сервера. Первый список мы применяем в директиве options. Разрешаем серверу обрабатывать запросы только от "наших" хостов (allow-query).
Опции директивы options распространяются на все зоны нашего сервера, поэтому, если мы хотим какую-либо из них обслуживать иначе, то должны в ее конфигурацию ввести изменения. Иначе мы обслуживаем зоны vega.ru и 43.226.194.in-addr.arpa:
// Corporative domain zone "vega.ru" { type master; file "vega.ru"; allow-query {any; }; allow-transfer { vega-friend; }; }; // Reverse corporative domain zone "43.226.194.in-addr.arpa" { type master; file "43.226.194.in-addr.arpa"; allow-query {any; }; allow-transfer { vega-friend; }; };
В описании этих зон мы применили список доступа vega-friend и только для этих зон разрешили обслуживание любых нерекурсивных запросов.
В принципе, можно было обойтись и без списков доступа, но в данном случае мы просто преследовали цель продемонстрировать способ их применения. Корпоративная сеть может быть развернута не на одной сети класса C, для дружественных сетей можно разрешить не только копирование зоны, но и удаленное ее (зоны) обновление. В этом случае списки увеличатся в объеме, и их копирование в разные части файла конфигурации может привести к нежелательным ошибкам.
Кроме того, при изменениях корпоративной сети и дружественных сетей вносить изменения придется только в списки управления доступом, а не в разбросанные по всему файлу описания. Использование списков управления (контроля) доступа - это более правильный стиль.
В BIND 9.х есть еще один механизм для определения различного поведения сервера при обслуживании запросов - "views".В материалах CERT для управления рекурсией приведена, например, такая конфигурация:
// Corporative domain view "internalview" { match-clients { internal; }; recursion yes; }; // Internet view "externalview" { match-clients { any; }; recursion no; };
Слово "internal" - это имя списка доступа, а слово "any" обозначение любого хоста Интернет.
На этом, пожалуй, можно и остановиться. Дальнейшее усложнение конфигурации сервера будет связано с вопросами безопасности и управления обновлениями зоны, но эти вопросы логичнее рассмотреть в других материалах, специально посвященных этим проблемам.
