Настройка кэширующего сервера в BIND 8.х и BIND 9.х
Отличие данного случая от случая BIND 4.х, описанного выше, заключается в том, что вместо named.boot мы должны создать файл named.conf, который имеет совсем другой формат управляющих директив. Вот пример его содержания:
options { directory "/etc/namedb"; }; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Это содержание файла named.conf полностью соответствует конфигурации BIND 4.х, которую мы разбирали выше.
Директива options определяет каталог, в котором хранятся файлы описания зон, директива zone определяет зоны, которые поддерживает сервер.
Зона "." сервером не поддерживается. Это корневая зона. Поэтому она имеет тип hint, т.е. "подсказка" на то, где описаны серверы корневой зоны.
Зона "0.0.127.in-addr.arpa" имеет тип master, т.к. данный сервер действительно является мастером для этой зоны.
Заметим, что по умолчанию в BIND 8.x и BIND 9.x файл named.conf расположен в разных каталогах. В BIND 8.x в каталоге /etc/namedb, а в BIND 9.х в каталоге /etc. Но, в принципе, используя параметры командной строки named этот порядок можно переиграть. Тем более его можно переиначить при сборке сервера из исходных текстов.
Теперь можно запускать named:
>named
Для BIND 8 сервер действительно запуститься, а вот для BIND 9.x этого скорее всего не произойдет. В файле системного журнала будет получено сообщение вида:
Nov 20 13:49:36 quest named[34123]: starting BIND 9.2.1 Nov 20 13:49:36 quest named[34123]: none:0: open: /etc/rndc.key: file not found Nov 20 13:49:36 quest named[34123]: couldn't add command channel 127.0.0.1#953: file not found
Для того, чтобы такое сообщение не появлялось нужно отменить удаленное управление сервером, которое обычно осуществляют через программу rndc:
options { directory "/etc/namedb"; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Мы просто вставили директиву controls с пустым содержанием.
Вообще говоря, лучше создать требуемые файлы ключей и работать через программу rndc, но в контексте данного материала, когда мы рассматриваем последовательно BIND 4.x - BIND 8.x - BIND 9.x, отмена контроля выглядит вполне логично.
На самом деле, конечно, такая простая конфигурация сервера не является хорошим стилем. Во-первых, мы создаем кэширующий сервер не для всех желающих, а только для хостов, которые мы обслуживаем, во-вторых, желательно не сообщать о том, что за версия сервера у нас установлена, в-третьих, существует еще несколько мелочей, которые желательно указать в файле настройки named.
Для того, чтобы отделить весь мир от "наших" хостов нужно создать список доступа:
acl "our_folks" { 192.168.1.0/24; }; options { directory "/etc/namedb"; allow-recursion { "our_folks"; }; allow-query {"our_folks"} version "unknown"; fake-iquery no; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
В данном файле конфигурации мы разрешили рекурсию (рекурсивные запросы) с нашей локальной сети, кроме того, разрешили какие-либо запросы (не только рекурсивные) тоже только с нашей локальной сети, скрыли версию named и отменили явно инверсные запросы (fake-iquery).
Вообще говоря, в данном случае можно было не вводить ограничения рекурсию, а ограничить только саму возможность обработки запросов (allow-query). Рекурсивные запросы - это только одно из подмножеств запросов и оно автоматически попадает на наложенное на обработку запросов ограничение.
Запрет на инверсные запросы - это тоже избыточная директива. Современные серверы этот тип запросов не поддерживают, а только корректно сообщают о таком своем поведении.
На самом деле в рекомендациях CERT (Computer Emergency Responds Team) есть еще несколько моментов, которые позволяют ограничить себя от разного сорта неприятностей с кэширующим сервером доменных имен.
В первую очередь это касается спуфинга, т.е. подмены отклика авторитативного сервера доменных имен поддельными пакетами в ответ на реальный запрос. Для этого необходимо, чтобы идентификаторы пакетов генерировались случайным образом.
В BIND 9.x это реализовано по умолчанию, а в BIND 8.x для этой цели нужно вставить опцию use-id-pool:
acl "our_folks" { 192.168.1.0/24; }; options { directory "/etc/namedb"; allow-recursion { "our_folks"; }; allow-query {"our_folks"} version "unknown"; fake-iquery no; use-id-pool yes; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Ограничение на исполнение рекурсивных запросов также повышает безопасность работы, т.к. не позволяет провоцировать сервер на запросы к зонам, находящимся под контролем злоумышленников, которые могут пытаться проделывать всякие предосудительные действия, например, "отравление" кэша вашего сервера.
В пакете BIND 9.x в комплект поставки входит легковесный resolver. Его функциональность не соответствует функциональности кэширующего сервера. Легковесный resolver может выполнять только рекурсивные запросы программного обеспечения, которое функционирует на том же самом хосте, где этот resolver запущен. Он не может обслуживать группу хостов.
