Настройка BIND версий 8 и 9
ВНИМАНИЕ: команды предваряемые символом '#' должны выполняться с правами root (Суперпользователь). Открыв терминал (или находясь в консоли) с правами обычного пользователя, введите команду $ su - для повышения уровня привелегий. Символы '$' и '#' в начале строки не являются частью команды и не должны вводится. Прочие команды могут выполняться с правами обыкновенного пользователя.
Содержание
Информация[править]
Named из пакета BIND 8-ой или 9-ой версий в своей настройке и управлении имеет ряд отличий от версии 4. Во-первых, файл конфигурации носит название named.conf и располагается по умолчанию либо в /etc (версия 9), либо в /etc/namedb (версия 8). Во-вторых, у named отсутствует хранимый на диске cache, описание корневой зоны вынесено в отдельный файл, и его нужно прописывать в настройках named. В-третьих, стало возможным дистанционно управлять named.
При запуске программа named читает файл named.conf и таким образом настраивается. Ранее были разобраны формат, структура и содержание файла настройки программы named версий 4.х. Учитывая тот факт, что "четверка" - это уже история, сосредоточимся теперь на файле настройки более свежих версий named.
Основные изменения, которые произошли с named, касаются повышения устойчивости сервера к различного рода атакам, что и отразилось в настройках. Администратор сервера получил возможность управлять копированием зон, обслуживанием запросов на разрешение имен ip-адресами (в данном случае слово "разрешение" употребляется в смысле "установка соответствия", а не в смысле "разрешить что-то делать"). Собственно, любая рекомендация перехода на новые версии named аргументируется более высокой защищенностью программы.
Внешним наиболее заметным отличием файла настройки версий 8.х и 9.х стал иной синтаксис. Он стал C-подобным (если бы новую версию программы начали делать сейчас, а не в 1997 году, то файл настройки получил бы наверное XML-синтаксис J).
Рассматривать все варианты конструкций в файле настройки named.conf, видимо не имеет смысла, а потому сосредоточимся только на наиболее часто встречающихся вариантах и наиболее привлекательных особенностях. При этом многие вопросы, связанные с безопасностью, динамическим обновлением и другими новыми возможностями оставим для отдельного обсуждения.
Прежде, чем приступить к обсуждению named.conf следует обратить внимание на место его расположения в файловой системе. Это важно, т.к. при установке named из портов (ports, т.е. установки двоичных, откомпилированных под определенную платформу версий named утилитами (скриптами) установки) место расположения этого файла может отличаться от того, которое выбирается по умолчанию, при установке из исходных кодов.
По умолчанию named.conf (установка из исходных кодов) располагается в каталоге /etc/namedb/ (версия 8) или /etc (версия 9). Как любая прикладная программа, named позволяет переопределить место положение своего файла настройки при помощи флага b или c в командной строке при своем запуске:
# named -c /etc/named.conf
Если Вы работаете с Unix-системой, то нужно внимательно посмотреть файлы конфигурации скриптов начальной загрузки и сами скрипты (обычно что-то типа rc.*, в разных клонах могут быть расположены в различных местах, но корнем пути к которым (местам), обычно, является каталог /etc, чтобы убедиться, что установки умолчания для named не переопределены.
И последнее замечание прежде, чем приступить к описанию примеров. Во всех примерах BIND 8-9 используются адреса, так называемых, немаршрутизируемых сетей. По этой причине будьте внимательны при копировании отдельных фрагментов примеров, если, конечно, Вы сочтете такое копирование полезным J.
Кеширующий сервер (Cache server)[править]
Как уже отмечалось ранее (см. "Типы серверов доменных имен") это сервер, который не отвечает ни за одну из зон, но используется для исполнения запросов resolver-ов. Он выполняет функции локального сервера доменных имен, т.е. выполняет рекурсивные запросы от прикладных программ к системе DNS. При этом в его кэш накапливается информация о соответствиях между доменными именами и IP-адресами, что позволяет существенно повысить скорость обработки запросов и разгрузить другие серверы доменных имен.
В соответствии со своими функциями кэширующий сервер будет иметь всего три файла настройки: файл named.conf, файл с описанием серверов обслуживающих корневую зону и файл описания обратной зоны для зоны 0.0.127.in-addr.arpa.
Формат, структуру и содержание двух последних файлов обсудим позже, а сейчас сосредоточимся на named.conf. Возьмем вариант из руководства по администрированию BIND версии 9:
// Two corporate subnets we wish to allow queries from.
acl "corpnets" {192.168.4.0/24; 192.168.7.0/24 };
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query {"corpnets";};
};
// Root server hints
zone "." {
type hint;
file "root.hint";
};
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};
В данном примере описана настройка кэширующего сервера для двух подсетей. Они перечислены в access control list (директива acl) и названы как "corpnet". Теперь в любом месте файла настройки можно ссылаться на этот список просто как на "corpnet", что, собственно и сделано в директиве options.
В директиве "options" вначале указан рабочий каталог named (опция directory). В нем располагаются все файлы, которые программа использует при своей работе, в том числе и файлы описания зон. Эта опция аналогична команде directory из файла настроек bind версий 4.х.
Затем опция pid-file указывает имя файла в которые будет помещен идентификатор процесса named. Этот файл будет расположен в рабочем каталоге named (т.е. /etc/namedb)
Последняя опция директивы options - allow-query. Она определяет список IP-адресов, для которых разрешено обращаться с запросами к серверу. Другие хосты обслуживаться данным сервером доменных имен не будут. Еще раз обращаем внимание на то, что любые другие хосты с любыми запросами не будут обслуживаться, т.е. не будут обслуживаться как рекурсивные, так и нерекурсивные запросы.
Директива "zone" позволяет описать местоположение и опции для обслуживания зоны. Две зоны обычно всегда описывают. Это зона "." (корневая зона) и обратная зона для адреса 127.0.0.1.
Описание зоны "." (корня дерева доменных имен) необходимо для того, чтобы сервер мог обращаться к "корневым" серверам, с запросами на получение справки о том, где искать "ответственного" за зону, из которой клиент хочет получить информацию (IP-адрес или доменное имя). По этой причине тип зоны определен как "hint", т.е. в буквальном переводе - "справочный", "ссылочный", "наводка на", "намек на", "совет" и т.п..
Само описание "корневых" серверов находится в файле root.hint. Файл поставляется вместе с дистрибутивом, но администратор должен следить за обновлениями этого файла. О том, как это делать мы рассмотрели подробно при описании настроек BIND 4 (cache файл).
Описание обратной зоны для 127.0.0.1 необходимо для того, чтобы можно было локально разрешать (получать соответствие между IP-адресом и именем) при обращениях с реверсивными запросами к зоне 0.0.127.in-addr.arpa. О важности реверсивных запросов будет сказано в разделе посвященном описанию обратной зоны для маршрутизируемой сети (подсети). Здесь мы только укажем, что описать данную зону нужно в целях соблюдения единообразия, отладки и аккуратной работы сервиса DNS.
Для зоны 0.0.127.in-addr.arpa наш сервер будет первичным (primary), поэтому его тип опцией type будет определен как master. В самом деле за эту зону отвечает только наш сервер. Адрес 127.0.0.1 за пределы хоста не маршрутизируется, поэтому у других серверов будет своя зона 0.0.127.in-addr.arpa.
Обратите внимание, что речь идет о кэширующем сервере, а определяем мы его и как master для одной из зон. В данном случае термин "кэширующий" говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.
Описание обратной зоны для 0.0.127.in-addr.arpa находится в файле "0.0.127.in-addr.arpa". Вообще говоря, файл может иметь любое имя, которое допускается файловой системой. На самом деле в документации по BIND 9.x для описания зоны используется имя "localhost.rev". Изменить имя в примере было нужно для того, чтобы отразить часто встречающуюся практику именования файлов описания зон именами самих зон. Еще раз подчеркнем, что имя может быть любым допустимым в контексте конкретной файловой системы именем.
Последняя опция "notify" позволяет реализовать режим оповещения об изменениях другие сервера, которые поддерживают данную зону, обычно, вторичные (резервные, secondary, slave). Для нашей обратной зоны это в принципе не нужно, поэтому опция установлена в значение "no". Если же говорить вообще, то не все серверы поддерживают этот режим. Общая практика заключается в том, что обновления "расползаются" по сети в соответствии с параметрами записи SOA из описания зоны.
Официальный (Authoritative) сервер зоны[править]
В руководстве по BIND данная конфигурация обозначена как "Authoritative-only server". Смысл ее заключается в том, что демонстрируется настройка сервера, который обслуживает запросы от любого хоста Сети, но только к той зоне, за которую он официально отвечает. В терминологии BIND 4.х такой сервер именовался как "primary" для зоны, а в терминологии BIND 8.х- 9.х он именуется как "master". Его файл настройки будет выглядеть следующем образом:
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query { any; }; // This is default
recursion no; // Do not provide recursion service
};
zone "." {
type hint;
file "root.hint";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};
zone "example.com" {
type master;
file "example.com";
allow-transfer { 192.168.4.14; 192.168.5.53; };
};
Сначала обратим внимание на отличие в описании опций директивы "options". Во-первых, с запросами к данному серверу позволено обращаться любому хосту Сети, что логично, т.к. никто другой кроме официального сервера в полном объеме за данную зону не отвечает (опция "allow-query"). Есть, конечно, вспомогательные сервера, но они только дублируют master сервер. Вносить изменения в описание зоны можно только на primary master сервере. Именно поэтому при выходе из строя primary master сервера время обслуживания запросов вспомогательными серверами ограничено. Предполагается, что при отказе primary master данные вспомогательных серверов не будут соответствовать исходному описанию зоны, а потому обслуживание запросов лучше прекратить.
Во-вторых, данный сервер не обслуживает запросы рекурсивно. Он только отвечает на запросы к своей зоне (опция "recursion"). Последнее означает, что в отличии от кэширующего сервера, который принимает запросы от клиентов (resolver-ов), опрашивает серверы доменных имен и потом отвечает клиентам, наш сервер запросы клиентов, которые не касаются зоны его ответственности обслуживать не будет.
Описание корневых (root) серверов и обратной зоны для 127.0.0.1 такое же, как и для кэширующего сервера.
При описании зоны ответственности (директива "zone "example.com") в качестве первого параметра указано имя зоны ("example.com") в фигурных скобках определены опции: тип сервера - master, т.е. официальный сервер зоны; файл описания зоны - file "example.com"; список вспомогательных серверов - "allow-transfer { 192.168.4.14; 192.168.5.53 };".
Собственно, опция "allow-transfer" задает список серверов, которым разрешено копировать зону. Официальными вспомогательными серверами они станут только в том случае, если они таковыми были определены в заявке (для доменов второго уровня - корпоративных доменов, например), либо приписаны таковыми при делегировании зоны более глубокого уровня.
Если не установить ограничения на копирование зоны, или указать "any", то любой сервер может скопировать зону, и не только сервер. Из соображений безопасности настоятельно рекомендуется прописывать адреса серверов, которым можно копировать зону.
Вспомогательный сервер (secondary, slave)[править]
В документации по BIND описание master сервера доменных имен и slave сервера совпадают. Но методически правильнее их разнести, что здесь и сделано.
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query { any; }; // This is default
recursion no; // Do not provide recursion service
};
zone "." {
type hint;
file "root.hint";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};
zone "eng.example.com" {
type slave;
file "eng.example.com";
masters { 192.168.4.12;};
};
То, что мы имеет дело с вспомогательным сервером для зоны "eng.example.com" определено в соответствующей директиве "zone". В качестве типа сервера (type) указано значение "slave", что и определяет сервер как вспомогательный. В опции "masters" определяется список официальных серверов, с которых вспомогательный сервер может списывать зону в файл "eng.example.com". В данном случае указан только один - 192.168.4.12.
Мы рассмотрели типовые настройки файла конфигурации named.Для того, чтобы двигаться дальше, нужно рассмотреть файлы описания зон.
Источники:
