Настройка named (BIND/ name server). Кэширующий сервер, slave и master

2004 г

Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Настройка named (BIND/ name server). Кэширующий сервер, slave и master

В этом материале будут разобраны различные версии нотации файла конфигурации программы named. Мы опишем также назначение некоторых директив файлов конфигурации и разберем типовые примеры для кэширующего, master и slave серверов.

Named - это сервер доменных имен пакета BIND. Named может реализовывать функции серверов любого типа: master, slave, cache (см. материал "Типы серверов доменных имен).

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

Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в 8-ой и 9-ой версиях BIND. В силу целого ряда причин имеет смысл рассмотреть оба формата файла конфигурации.

Файл конфигурации BIND 4

Всего существует три типа файлов, которые использует named 4-ой версии. К ним относятся:

файл начальной загрузки буфера (cache)
конфигурации named (named.boot)
файлы описания "прямых" и "обратных" зон

В литературе по named принято начинать с файла описания базы данных named - named.boot. Еще раз напомним, что более свежие версии named настраиваются при помощи файла конфигурации, имеющего другое имя и другой формат директив.

Файл named.boot в 4-ой версии используется программой named для своей настройки и первичной загрузки базы данных домена. Это первое, что ищет named при своем запуске.

Терминология при работе с named из BIND 4 отличается от той, которая принята в настоящее время. Master сервер зоны в данном случае будет называться primary сервером зоны, slave сервер зоны будет называться secondary сервером зоны.

В файле named.boot для описания настроек named используются следующие команды:

directory - адрес директории в файловой системе компьютера, на котором запускается named.
primary - определяет зону, для которой данный сервер является primary server, и имя файла базы данных этой зоны. Файл размещается в директории, которая указана в команде directory.
secondary - определяет зону, для которой данный сервер является secondary server, а также определяет адреса других серверов для этой зоны, обычно primary server, и имя файла где будет вестись копия базы данных этой зоны. Файл размещается в директории, указанной в команде directory.
cache - определяет имя кэш-файла. Обычно в кэш-файле описаны адреса и имена корневых серверов, которые данный сервер будет использовать для получения адресов удаленных серверов доменных имен.
forwarders - данная команда определяет адреса серверов доменных имен куда следует отправлять рекурсивные запросы. Естественно, что на этих серверах для хоста, на котором установлен named, должна быть разрешена обработка рекурсивных запросов с этого хоста.
slave - заставляет сервер отправлять все запросы на серверы, которые определены командой forwarders.

Прежде, чем рассматривать примеры файлов named.boot для различных типов серверов, хотелось бы обратить внимание читателя на две последние команды.

Фактически, именно они и определяют какая из процедур разрешения запроса (рекурсивная или нерекурсивная будут применяться на вашем сервере в каждом конкретном случае). Если в файле named.boot есть команда slave, то определена рекурсивная процедура разрешения запроса, т.к. в этом случае named будет отсылать все запросы на серверы указанные в команде forwarders и от них получать адреса или имена удаленных хостов. В этом случае серверы из forwarders будут опрашивать корневые серверы и удаленные серверы доменов. Если эти серверы также содержат команду slave, то поиск адреса или имени будут осуществлять серверы, которые определены в их файлах named.boot как forwarders.

Когда такая конфигурация сервера полезна? Обычно так настраивают кэширующие серверы подразделений внутри одной организации. В качестве сервера, на который осуществляется пересылка всех запросов, используется центральный сервер организации. При этом с корневыми серверами общается только этот сервер, серверы зон самостоятельно на корневые серверы запросов не отправляют. Если число машин за пределами данного домена, с которыми общаются пользователи этого домена, не очень велико, и все они компактно расположены в других доменах, то центральный сервер домена быстро заполнит свой кэш необходимой для разрешения запросов информацией. При этом такой кэш будет только один, а работать он будет с той же скоростью, как если бы каждый из серверов зон создавал его у себя.

Приведем теперь пример файла named.boot, в котором проиллюстрируем использование указанных выше команд:

;An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru vega
primary 43.226.194.in-addr.arpa vega.rev
secondary polyn.kiae.su 144.206.130.137 144.206.192.34 polyn
secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 polyn.rev
cache   .                       named.root

Пример 1. Содержание файла named.boot.

Обычно, файл named.boot размещается в директории /etc. От этой директории затем идет отсчет места компонентов базы данных named. В нашем случае эту базу данных можно представить в виде графа (рис.1), у которого в качестве корня выступает директория /etc. В /etc существует поддиректория namedb, в которой располагаются все остальные файлы.

Рис.1. Структура размещения файлов базы данных named из примера 1.

Сопоставив рисунок 1 и описание из примера 1, легко догадаться, что последняя колонка в каждой из команд описания настроек named заканчивается именем соответствующего файла или директории. Рассмотрим формат каждой команды более подробно.

Команда directory определяет директорию namedb как директорию размещения файлов базы данных named (файлов описания зон). Вообще говоря, вовсе не так уж обязательно размещать все файлы в одной директории. Можно создать несколько директорий, например, по количеству зон. Например, для каждой зоны можно использовать отдельную поддиректорию в корневой директории named. Если придерживаться этой логики размещения файлов, то

;An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru v/vega
primary 43.226.194.in-addr.arpa v/vega.rev
secondary polyn.kiae.su	144.206.130.137 144.206.192.34 p/polyn
secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 p/polyn.rev
cache   .                       named.root

Пример 2. Содержание файла named.boot при размещении файлов описания зон для primary и secondary серворов по разным директориям.

В примере 2 в директории namedb определены две поддиректории v и p. В директории v размещаются файлы зон vega.ru и 43.226.194.in-addr.arpa, для которых данный сервер является primary. В свою очередь в директории p размещаются файлы описания зон polyn.kiae.su и 160.206.144.in-addr.arpa, для которых данный сервер является secondary сервером. Если представить структуру файлов в виде графа, то получится граф с рисунка 2.

Рис.2. Дерево файлов описания базы данных named из примера 2.

Вообще говоря, корнем описания файлов базы данных named может быть директория отличная от /etc. если программу named запустить с флагом "-f", то в качестве параметра можно указать полный путь к файлу named.boot или к другому файлу, который используется вместо named.boot:

/usr/paul>named -f /usr/paul/named.par

В этом случае в качестве корневой директории для файлов описания базы данных named будет использоваться директория /usr/paul, а в качестве файла named.boot файл named.par из этой директории.

Кроме того, в команде directory, как это определено в наших примерах, используется, так называемый, неполный путь к директории, где расположены файлы базы данных named. Однако можно указывать и полный путь, что дает возможность расположить эти файлы где угодно в файловой системе сервера. Например, если файлы расположены в директории /usr/local/etc/namedb, то в файле named.boot следует указать следующую команду directory:

directory /usr/local/etc/namedb

Команда primary используется для указания зоны, которую данный сервер обслуживает в качестве master сервера, и указания имени файла, где она (зона) описана. Формат команды primary можно описать следующим образом:

primary <имя зоны> <имя файла описания зоны>

В примерах 2 и 3 используется три команды primary. Первая описывает "обратную" зону 0.0.127.in-addr.arpa, вторая команда описывает "прямую" зону vega.ru и третья команда описывает "обратную" зону 43.226.194.in-addr.arpa. Наличие двух "обратных" зон вызвано тем, что прямая зона определена на двух сетях - 194.226.43.0 и 127.0.0.0.

Сеть 127.0.0.0 - это особая сеть, поэтому первая команда должна быть на любом сервере доменных имен, т.к. она служит для определения обратной зоны 0.0.127.in-addr.arpa, которая закреплена за любой машиной, на которой установлен стек протоколов TCP/IP.

Особое назначение этого домена следует из особого значение IP-адресов, которые закреплены за ним. Они обозначают "петлю", т.е. при отправке пакетов по адресу, например, 127.0.0.1 пакеты не выходят за пределы одного компьютера и таким образом не попадают в реальную сеть. В некоторых реализациях стека определенное значение имеют и другие адреса сети 127, например, 127.0.0.2 и 127.0.0.3 в HP-UX.

Очень часто в примерах описания файла named.boot можно встретить повторение имени зоны в названии файла:

primary 0.0.127.in-addr.arpa 0.0.127.in-addr.arpa

Это повторение означает только то, что в директории файлов описания базы данных named должен быть файл с таким именем. Для тех, кто привык к тому, что в файловой системе MS-DOS были разрешены только трехбуквенные расширения имени файла, подобное имя выглядит довольно странно, но у энтузиастов Unix и пользователей современных версий Windows это не должно вызывать затруднений. Использование имен зон в качестве имен файлов - это общепринятая практика. Так гораздо проще ориентироваться среди файлов описания базы данных named.

Часто вместо 0.0.127.in-addr.arpa указывают 127.in-addr.arpa. Сеть 127 - это сеть класса А (Для тех, кто привык к нотациям CIDR рекомендуем прочитать RFC-790 и 791). Для этой сети что 127, что 127.0, что 127.0.0 - суть одно и тоже. Так как при указании обратной зоны числа в IP-адресах указываются в обратной последовательности, то 0.0.127.in-addr.arpa и 127.in-addr.arpa также означают одно и тоже. Вообще говоря, обработка этой обратной зоны согласно RFC-1035 производится особым способом.

Среди специалистов по named нет единства мнений о стиле определения прямых и обратных зон, в том числе, и о зоны 0.0.127.in-addr.arpa. Некоторые предлагали ввести "прямую" зону, которая бы соответствовала "обратной" зоне 0.0.127.in-addr.arpa. Связано это с доменным именем, которое ставится в соответствие адресу 127.0.0.1.

Команда secondary используется для описания зон, где данный сервер выполняет функции slave сервера, и имеет следующий формат:

secondary <имя зоны> <список IP-адресов серверов зоны> <имя файла описания зоны>

В наших примерах описано две зоны, для которых данный сервер является secondary сервером - polyn.kiae.su и 160.206.144.in-addr.arpa. В примерах для каждой из этих зон указано по два IP-адреса серверов, поддерживающих зону.

Вообще говоря, достаточно указывать адрес только primary сервера зоны. С точки зрения актуальности состояния базы данных зоны, для которой создается secondary сервер, указание одного только primary наиболее правильное решение, т.к. только primary сервер содержит наиболее актуальную базу данных зоны. Однако в ряде случаев, имеет смысл указать несколько серверов, primary и secondary, например. В случае указания нескольких серверов, база копируется с того, который указан первым, если он доступен. Если сервер не доступен, то опрашивается следующий в списке, до первого доступного сервера.

Файл, который указан последним аргументом в команде secondary, создается named при запуске и постоянно обновляется в соответствии с описанием взаимодействия master и slave серверов. Редактировать вручную этот файл не имеет смысла, т.к. это калька с master сервера, и через постоянные промежутки времени этот файл обновляется программой named. Таким образом, если кто-либо и внесет в него изменения, то named, создавая новую копию базы данных зоны, затрет эти изменения.

В отличии от master сервера slave сервер не способен поддерживать разрешение запросов сколь угодно долго. Как только истечет время актуальности данных в его базе данных, он пытается создать новую копию базы с базы данных master сервера. Если это не удается, то сервер через некоторое время перестанет обслуживать зону (см. описание записи описания ресурсов SOA).

Главное назначение slave сервера - это повышение надежности службы доменных имен. Описание зоны named копирует с серверов, указанных в качестве аргумента команды secondary. Там указаны не только primary master сервер, но и другие серверы, которые относительно primary master являются slave серверами.

Зона копируется с того сервера, который доступен. Это значит, что на данном сервере может оказаться копия с другого slave сервера.

Команда cache служит для определения файла с начальными данными для запуска named. Для того, чтобы начать отвечать на запросы named должна знать адреса других серверов доменных имен, к которым можно было бы обратиться с запросами на разрешение IP-адреса по имени или имени по IP-адресу. Формат команды выглядит следующим образом:

cache <имя зоны> <имя файла cache>

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

Согласно Крегу Ричмонду (Craig Richmond) различные версии named по разному используют файл, указанный в команде named. Одни программы загрузив данные из этого файла больше его не используют, другие наоборот постоянно вносят в него изменения.

В случае стабильного файла администратор системы должен сам заботится о его актуальности. Для этого он должен регулярно проверять соответствие между его файлом и файлом, который поддерживается в ns.internic.net. Получить копию файла можно либо, с ftp-сервера ftp.rs.internic.net, либо по команде:

/usr/paul>dig @ns.internic.net.ns > root.cache

Том Ягер (Tom Yager) рекомендует другой источник получения cache - ftp://nic.ddn.mil/netinfo/root-servers.txt.

На самом деле cache - это описание корневой зоны доменных имен, которую, собственно, и обслуживают root серверы. А куда еще прикажите обращаться при запуске named?

Если в файл cache необходимо внести другую информацию, то это делается аналогично описанию корневых серверов. В новых версиях named (8-9ая) нет кэш-файла, но есть описание корневой зоны. По этой причине не стоит вносить в него изменения, которые не сделали на primary master корневой зоны.

Команда forwarders определяет IP-адреса серверов, на которые следует отправлять рекурсивные запросы. Команда имеет следующий вид:

forwarders <список IP-адресов серверов>

Случай организации рекурсивной процедуры разрешения имени с использованием этой команды был рассмотрен ранее. Однако этим случаем не ограничивается круг использования команды forwarders. При регистрации домена некоторое время внешний относительно этого домена мир не подозревает о существовании домена. Должно пройти некоторое время, прежде чем будет закончена процедура регистрации домена и обновления баз данных вышестоящего в иерархии DNS домена на всех серверах как master, так и slave. Однако внутри домена все работает нормально, т.к. локальный сервер запускается до официальной регистрации и способен обслуживать машины домена. Однако, он может и не знать информации о всех доменах Internet. Для этого нужно самому запрашивать root-серверы. Но можно ведь воспользоваться и чужим кэшем. По этой причине всегда полезно указать команду forwarders на сервер домена вышестоящего относительно данного домена. Как правило, на нем разрешено обслуживать рекурсивные запросы хостов из поддоменов.

Обычно указывают не один, а несколько IP-адресов серверов, которые в состоянии ответить на запросы клиентов. Например, для сервера зоны vega.ru, который запущен, но еще не зарегистрирован, можно указать два сервера:

forwarders 144.206.136.1 144.206.130.137

Команда slave указывается тогда, когда сервер общается с внешним миром чрез серверы, указанные в команде forwarders. Параметров у данной команды нет. Файл named.boot для того сервера, если он еще и primary сервер для зон vega.ru и 43.226.194.in-addr.arpa будет выглядеть следующим образом:

;An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru vega
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root
forwarders 144.206.130.137 144.206.136.1
slave

Пример 3. Подчиненный сервер, работающий по рекурсивной процедуре разрешения запросов от resolver.

Фактически, команда slave позволяет организовать, в некотором смысле, "интеллектуальный" resolver.

Настройка BIND версий 8 и 9.

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.Для того, чтобы двигаться дальше, нужно рассмотреть файлы описания зон.

Рекомендованная литература:

Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
J. Postel . ASSIGNED NUMBERS. RFC 790. (http://www.ietf.org/rfc/rfc0790.txt?number=790)
J. Postel .INTERNET PROTOCOL. RFC 791. (http://www.ietf.org/rfc/rfc0791.txt?number=791)
P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)

Полезные ссылки:

http://www.ludd.luth.se/~kavli/BIND-FAQ.html - FAQ первоначально написанные Craig Richmond и в настоящее время поддерживаемые Ronny H. Kavli. Предназеачены главным образом для BIND версии 4.
http://www.die.net/doc/linux/man/man5/named.conf.5.html - страницы документации по named.conf для любителей Linux.
http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=named.cont - то же самое, что и пункт 2, но только для любителей FreeBSD.

Назад Оглавление Вперед