Всего существует три типа файлов,
Всего существует три типа файлов, которые использует named 4-ой версии. К ним относятся:
В литературе по named принято начинать с файла описания базы данных named - named.boot. Еще раз напомним, что более свежие версии named настраиваются при помощи файла конфигурации, имеющего другое имя и другой формат директив.
Файл named.boot в 4-ой версии используется программой named для своей настройки и первичной загрузки базы данных домена. Это первое, что ищет named при своем запуске.
Терминология при работе с named из BIND 4 отличается от той, которая принята в настоящее время. Master сервер зоны в данном случае будет называться primary сервером зоны, slave сервер зоны будет называться secondary сервером зоны.
В файле named.boot для описания настроек named используются следующие команды:
Прежде, чем рассматривать примеры файлов 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
В наших примерах описано две зоны, для которых данный сервер является 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, но также и другие серверы, которые часто используются для разрешения запросов в вашем домене.
Согласно Крегу Ричмонду (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
Случай организации рекурсивной процедуры разрешения имени с использованием этой команды был рассмотрен ранее. Однако этим случаем не ограничивается круг использования команды 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.
