Named руководство по

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

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

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

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


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

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

Next


© Copyright 2023, Internet Systems Consortium.
Revision 1b0512fa.

Built with Sphinx using a
theme
provided by Read the Docs.

��������� �������� � �������. ������ ����� ��������� ������ �� ���������
(��������� ��� ���������) ���.
��� ����� ����� ���� ������������ �� �������� ��������. ����������:
������ ���� ����� ����� ������������ ���������
���������� ����� «options no-recursion».

������ �������������� �������� �������������� ��� ��� ���������� �����.
���� ������� ��������� ��������� ������, ������������ ��������� �� ���.

��������� ���� �������� ���������� � ���, ��� ������ ���� ������ �����
��������� ������. ������ ��������� ���������� ����� ������ �������������
����� �� ����� ������. ���� �������� ��������� ������ ���������� �����:

         ;
         ;    boot file for name server
         ;
         directory /usr/local/adm/named
         ; type      domain                source host/file          backup file
         cache       .                     root.cache
         primary     Berkeley.EDU          berkeley.edu.zone
         primary     32.128.IN-ADDR.ARPA   ucbhosts.rev
         secondary   CC.Berkeley.EDU       128.32.137.8 128.32.137.3 cc.zone.bak
         secondary   6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
         primary     0.0.127.IN-ADDR.ARPA  localhost.rev
         forwarders  10.0.0.78 10.2.0.78
         limit       transfers-in 10
         limit       datasize 64M
         limit       files 256
         options     forward-only query-log fake-iquery
         check-names primary fail
         check-names secondary warn
         check-names response ignore

��������� «directory» ������ ������� ���������� ������� ��
��������� � ��������� ���� ���������. ��� ����� ���� �����
��� ���������� ��������� ��������� ���������� $INCLUDE ������ �
����� ��������� ���.

��������� «cache» ���������, ��� ���������� ����� «root.cache»
������ ���� ������� � ��� ������� ��� ������. �������� ��� ��������������
����������� � �������� �������������� �������� ��������.
���� ��� �� ������������ ��� ���������� ������, �� ���������
� �������� «���������» ��� ������ ������� �������� ��������.
���� «root.cache» ����� ��� �� ������, ��� � «berkeley.edu.zone».
���������� «cache» ����� ���� ������� ����� ������ �����.
���� «root.cache» ���������� ��������� ��������� ��
FTP.RS.INTERNIC.NET, ��������� �� �������� ������������ ������������
������ �������� ��������.

������ ��������� «primary» ���������, ��� ����
«berkeley.edu.zone» �������� ������������ ������ �� ����
«Berkeley.EDU». ���� «berkeley.edu.zone»
�������� ������ � ������� ������-�����, ��������� � RFC
883. ��� �������� ����� ����������� ������������ ��������� ������ (origin),
� ������ ������ «Berkeley.EDU» (����� �������� ��. ����).
������ ��������� «primary» ���������, ��� � �����
«ucbhosts.rev» ��������� ������������ ������ �� ������
«32.128.IN-ADDR.ARPA», ������� ������������ ��� ����������
IP-������� � ���� 128.32 � ����� ������. ������� �� ������-������
������ ���������� � ������ SOA ��� ��������� � ��� ���� (��.
����).

������ ��������� «secondary» ���������, ��� ���
������������ ������ �� ���� «CC.Berkeley.EDU» ������
����������� � ������� �� ������ 128.32.137.8. ���� ��� ������ �������
�� �������, ���������� ���������� ������� �� � ������� �� ������
128.32.137.3, � ��� �����, ������ � ���� ��������� ����� ���� �������
�� 10 ����� �������. ��������� ����� ����� ���������
������������ ��� ���������� ������. ������ ��� � ���� ���������,
�� ���������� IP-������� (�������� �� ������� �����, �����������
�������), �������������� ��� ��� �����, � ������� �����
��������� ��������� ����� �������� ������ �� ����.
������ �������� ������ �� ���� �� ���� ��������� �����,
����������� ������ ���� ���� � ��� ������, ���� ���������
������� ����� ����������. ��������� ����� ����� ����������� �����
������� ��������� ����������, ����������� ������������� � ������ ��
��������� ��������. ���� ��� ����� ��������� ����� �� �������,
������ �� ���� ����� ����������� �� ��������� �����, �������
����� ������ ����� ������� ��������� ������ ����. ��� �� �������������
������ ��-�� �������������� ��������� �������� ��������.
������ ��������� «secondary» ���������, ��� ��������� ����� ������
��� ���������� ������� � ����� ������� 128.32.136 ������ ����������
� ��� �� ��������, ��� � ��� ��� ���������� ����.

��������� «forwarders» ��������� ������ ��� �������� � ��������
����, ������� ������������ ����������� ������� �� ������ ��������.
���� � ��������� ����� ������� ����� ������ ������ �������, ��
�������� ������ ������������ ��� �������, ��� ������� ��� ������
� ����, ������� ��. � �������� ��������������� ������� ����� ��������
��� ������� � ������ «forwarders» �� ��� ���, ���� �� �����
������� ����� ���� �������� ��� ������. ���� ����� ���-���� �� �����
�������, �������� ������ ��������� ������ ���, ��� ���� �� �� ������
������� � ����������� �������� �� ���� ������� (���� ������ �� ��
�������� � ������ «forward-only», �� ���� «������ ���������������
��������»). ����������� ��������������� �������� ������ ������� ���
�������� �������� ���� � �������� ���� �� ������-������� �, ��� ���������,
���������� �������� �������� ��� �������� � ������� ��������.
��� ����� ����� ���� �������� ��� ��������, �� ������� ������� �����������
� Internet, �� ��������, ��� �� �����, ����������� ����� ������� ����.

��������� «slave» (� ��������� ����� ����������) ������������ ���
�������� �������������. �� �������� ��������� ���������� ���������
«options forward-only».

��������� «sortlist» ����� �������������� ��� �������� ����������
����� ����� ��� �������. ��� ���� ����� ��������� � ��������� ����
������������� ��������� �������: ������� ��� ��������� �������
������ ���������� ������ ���� � �������� ��������� ����, �����
��������������� ������ �������, �������������� � ��������� «sortlist»,
� ����� ��� ��������� ������.

��������� «xfrnets» (� ������� �� ��������) ����� ��������������
��� ����������� �������� �������. ��� �������� ���� ���������
������ ����� �������� �� ������� �������� ���� ������ �� ���
������, ������� ��������� � �����, ��������� � ���������
«xfrnets». ������, ����������, �������� ���� ��������� —
«tcplist».

��������� «include» (� ������� �� ��������) ����� ��������������
��� ��������� ������� �����, ��� ���� �� ��� ���������� ���� ���������
������ ����� ��������� «include». ��� ������ ������� ��� �������
�������� ���������� ��� ���� ��� ���������� ����������� ���,
�������������� ������� ������. ��������� «include» ����� ���� ��������,
���������� ������ ����������� �����, ��� ���� ���� ��� ����� � �������
(���� ������ ������������) �� �����������.

��������� «bogusns» (� ������� �� ��������) �������� ������� BIND,
��� �������� � ���������� � ��� IP-�������� ������ �������� �������
��������. ��� ����� ���� �������� � ��� ������, ����� � ������-����
����������� ������� ���������� �������� ��� ����������� ������ � ���
���� ���� ����, � �� ������ �������� ��������� � ���� �� ��� ���, ����
�������� �� ����� ����������.

��������� «limit» ������������ ��� ��������� ���������� ����������
������� ������� BIND, ������ ��������� �� ��� (datasize, ��������)
����������� �� ��������� ������, � ������ (����� transfers-in)
�� ������ ����� BIND. ��� �����, ����������� �������� �������� � ���������
�� ������� ���������� �������, ����� ����������� ���������
«k,» «m» ��� «g», ���������� ���������, ��������� � ���������
��������������. �������� ��������� datasize
������������� ������ ����� ������ ��������, �������������� ������ �����.
����������: ���� ��������� ����� ���������� �� �� ���� ��������
— �� ����� �������� ������������� ��������� datasize ���������
«limit» �������� � ��������� ���������������� ���������.
���������� ��������� transfersin �������� ������������ ����������
������������ named-xfer, ����������� BIND ������������.
���������� ��������� transfers-per-ns �������� ������������ ����������
������ �������, ������������ ������������ � ����� �������� ��������� ��������
����. �������� ��������� files ������������� ������������
���������� ������������ ������, ��������� ��������. ����������:
���� ��������� ����� ���������� �� �� ���� ��������
— �� ����� �������� ������������� ��������� files ���������
«limit» �������� � ��������� ���������������� ���������.

��������� «options» ���������� ���������� ��������, ����������
��������� ������� BIND. � ����� ��������� ����� ���� ������� ���������
����������. ���� ����������� �����, ������������ � ��������� �����.
no-recursion — ���������� ������ ���� ��������
������� �� ����� ������������ ������, ������ ������ �������,
��� ������� ������� �����, �� ������� ��� ������ �� ��������
�������������. �� �������������� ��� ����� �� �������, ������ �� �������
���� � ����� resolv.conf ������ �����.
no-fetch-glue — ���������� ������ ���� �� ������ ����� ���
�������� ��������� ����� ��� ��������������� ������ «additional data»
(�������������� ������) ������. ��� ����� ����� �������������� � ���������
� ������ no-recursion � ����� �������������� ���������� ����
BIND ��� ��� ����������. query-log — ���������� �����������
��� ������� � ��������� ������� ����������� syslog(8).
��� �������� � �������� ����� ���������� �������, ������� �� �����������
���� ������ ��� �������������. forward-only — ���������� ������
������ �������������� ������� ������ �������� � ������������ ������������
������� (forwarders). ������ ��� ����� ������������ �� ������, �� �������
������� ������ ����, �� ������� �� ���������� ���� ����������������
�������� �� ����� ����� ������� � Internet. fake-iquery
���������� ������ �������� ������� ����������� ������ �� «���������
�������». ��� ����� ���� ��������, ���� ���� ���� ������� �� ����������������
��� ����� � SunOS ��� � ���, � ������.

��������� «check-names» ��������� ������� BIND ��������� �����
� ������ ��� ��������� («primary»), ��� � ��������� («secondary») ���,
� ����� � ���������� («responce»), ���������� �� ����� ������������
������� (��������, ��� ��������� ������� �� �����, ������������ ��
������� ������� (firewall)). �� ������ ��� ����� BIND ����� ��������� ����
����� ���� «fail» (�������), ��� ���� ����� ���� �� ����� ���������,
� ������ �� ����� ��������� ��� ��������� ������ ��� ������������ �������,
���� ����� ���� «warn» (��������������), � ���������� ���� �� ��� ���
������ ����������� ��������� � ��������� �������, ���� ����� ����
«ignore» (������������), � ����� ��� ����� ���������� ������� ��������,
�������� �� ��� ��������� ��������������. ����� ��������� �����������,
���� ��� �������� ������������� RFC 952 (���� ��� ����� ������) ����
������� ������ �� ���������� ASCII-�������� (���� ��� �� ��������
������� ������).

��������� «max-fetch» (� ������� �� ��������), � ��������� ����� ����������,
������������ ��� �������� �������������. �� �������� ��������� ����������
��������� «limit transfers-in».

������-���� ������� �� ����������� ���������� � ������
������� �������� ��� �������� ���� � ��������� ��������:

        $INCLUDE <���_�����> <������_�����>
        $ORIGIN <�����>
        <�����> <������_�����_�����> <������_�����> <���> <������_�_��������_��������>

��� domain — ��� «.» ��� ��������� ������,
«@» ��� ������� ���� (origin) ��� ����������� ��� ������.
���� domain �������� ����������� ������ ������,
�� ��������������� «.», �� � ��� ����� ����������� ��� ������� ����.
����� �������, ��������������� «.», �������� �����������.
���� ������_����� ������������ ��� ����������� ������� ����
��� ������, ����������� �� ���������� �����. ��� ������������ ���������
��������� $ORIGIN ����� ������ ������� ����������� �����. ��� ����
�������������. �� ���� opt_domain, �� ��������� $ORIGIN ��
���������� ����� �� ������ ������� ���� ��� ����� �����.
���� ������_�����_����� �������� �������������� ����� ������,
����������� ����� ����� ����. �� ��������� ��� ��������������� � ����,
���������� ����������� ��������, ��������� � ������ SOA ����.
���� ������_����� ��������� �� ��� ������ �������; � ���������
����� �������������� ������ ���� ���, IN, ��� ��������,
������������ � DARPA Internet. ���� type ��������
���� �� ���������� ���� ������; ������ ������, ��������� � ����
resource_record_data, �������� ��� ��, � �������.

���������� � ����� (���_���������� ���_��)

������ �������� ������ ������������� � ����� ������, ��
�� ������ ���������� �� �� ������� ����� ������, ���� ���������
������ � ������� ������. ����������� ��������� �������� ����� �
������� («;») � ������������ �� ����� ������.

��������, ��� ���������� � ������ ���� ������� ��������, ��
���������� �����. ��� ������� ������ ����� �������� ��� �
BIND Operations Guide («BOG»). ��������� �� ����� �������
�������� ����� ���� ��������������� � ����� �� RFC, �� ��� ��
����������� � ���� ������ BIND.

������ ������-���� ���� ������ ���������� � ������ SOA («start
of authority», ������ ���������������) ��� ����. ���� ��������
������ ������ SOA:

@ IN SOA ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
         1989020501 ; �������� �����
         10800      ; ����������
         3600       ; ����� �������
         3600000    ; �����������
         86400 )    ; ����������� ����� �����


������ SOA ��������� �������� �����, ������� ������ ���� ������� ������
��� ��� ��������� ������-�����. ��������, ��� �������� ����� �����
�������� �� �����, ����������� ������, �� ����� ������
������������ �� �������������, ��������� ������� � �������
����� �������� ������ �������������, � �� ������� ��������� � ����������.
� �������� ������ ����� ������� ���, �����, ����� � ����� ������ � ��������
0..99 � ��� ��� �������� � �������� 32-������� ������������ ������.
��, ��� ��������� �������� ������������ � 4294 ���� �� ��������������
���������, �� ���� �� ����� �� ���� �� ������������. ��������� �������
��������� �������� ����� � ���������, �������� ����� «����������»
� ��������; ���� �� ��� ����� �������� ����� ���������, �� ��� ����������
������ ����� � ��������� ����� ������. ���� ������-������ ����������
�� ������� ����������, �� ����� ������� ������� ������ ����� �����������
����� �����, �������� � ���� «����� �������». ���� ������-������
�� �������� ����� �������, ��������� � ���� «�����������», �� ������
�� ���� ��������� ���������� ���������. ���� «����������� ����� �����»
(«TTL») ������������ ���� �������� �����, ��� ������� ��� ���� ��
������� ����.

named — Man Page

Internet domain name server

Examples (TL;DR)

  • Read the default configuration file /etc/named.conf, read any initial data and listen for queries: named
  • Read a custom configuration file: named -c path/to/named.conf
  • Use IPv4 or IPv6 only, even if the host machine is capable of utilising other protocols: named -4|-6
  • Listen for queries on a specific port instead of the default port 53: named -p port
  • Run the server in the foreground and do not daemonize: named -f

tldr.sh

Synopsis

named [ [-4] | [-6] ] [-c config-file] [-C] [-d debug-level] [-D string] [-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-X lock-file]

Description

named is a Domain Name System (DNS) server, part of the BIND 9 distribution from ISC. For more information on the DNS, see RFC 1033, RFC 1034, and RFC 1035.

When invoked without arguments, named reads the default configuration file /etc/named.conf, reads any initial data, and listens for queries.

Options

-4

This option tells named to use only IPv4, even if the host machine is capable of IPv6. -4 and -6 are mutually exclusive.

-6

This option tells named to use only IPv6, even if the host machine is capable of IPv4. -4 and -6 are mutually exclusive.

-c config-file

This option tells named to use config-file as its configuration file instead of the default, /etc/named.conf. To ensure that the configuration file can be reloaded after the server has changed its working directory due to to a possible directory option in the configuration file, config-file should be an absolute pathname.

-C

This option prints out the default built-in configuration and exits.

NOTE: This is for debugging purposes only and is not an accurate representation of the actual configuration used by named at runtime.

-d debug-level

This option sets the daemon’s debug level to debug-level. Debugging traces from named become more verbose as the debug level increases.

-D string

This option specifies a string that is used to identify a instance of named in a process listing. The contents of string are not examined.

-E engine-name

When applicable, this option specifies the hardware to use for cryptographic operations, such as a secure key store used for signing.

When BIND 9 is built with OpenSSL, this needs to be set to the OpenSSL engine identifier that drives the cryptographic accelerator or hardware service module (usually pkcs11).

-f

This option runs the server in the foreground (i.e., do not daemonize).

-F

This options turns on FIPS (US Federal Information Processing Standards) mode if the underlying crytographic library supports running in FIPS mode.

-g

This option runs the server in the foreground and forces all logging to stderr.

-L logfile

This option sets the log to the file logfile by default, instead of the system log.

-M option

This option sets the default (comma-separated) memory context options. The possible flags are:

  • fill: fill blocks of memory with tag values when they are allocated or freed, to assist debugging of memory problems; this is the implicit default if named has been compiled with —enable-developer.
  • nofill: disable the behavior enabled by fill; this is the implicit default unless named has been compiled with —enable-developer.
-m flag

This option turns on memory usage debugging flags. Possible flags are usage, trace, record, size, and mctx. These correspond to the ISC_MEM_DEBUGXXXX flags described in <isc/mem.h>.

-n #cpus

This option creates #cpus worker threads to take advantage of multiple CPUs. If not specified, named tries to determine the number of CPUs present and creates one thread per CPU. If it is unable to determine the number of CPUs, a single worker thread is created.

-p value

This option specifies the port(s) on which the server will listen for queries. If value is of the form <portnum> or dns=<portnum>, the server will listen for DNS queries on portnum; if not not specified, the default is port 53. If value is of the form tls=<portnum>, the server will listen for TLS queries on portnum; the default is 853. If value is of the form https=<portnum>, the server will listen for HTTPS queries on portnum; the default is 443. If value is of the form http=<portnum>, the server will listen for HTTP queries on portnum; the default is 80.

-s

This option writes memory usage statistics to stdout on exit.

NOTE:

This option is mainly of interest to BIND 9 developers and may be removed or changed in a future release.

-t directory

This option tells named to chroot to directory after processing the command-line arguments, but before reading the configuration file.

WARNING:

This option should be used in conjunction with the -u option, as chrooting a process running as root doesn’t enhance security on most systems; the way chroot is defined allows a process with root privileges to escape a chroot jail.

-U #listeners

This option tells named the number of #listeners worker threads to listen on, for incoming UDP packets on each address. If not specified, named calculates a default value based on the number of detected CPUs: 1 for 1 CPU, and the number of detected CPUs minus one for machines with more than 1 CPU. This cannot be increased to a value higher than the number of CPUs. If -n has been set to a higher value than the number of detected CPUs, then -U may be increased as high as that value, but no higher.

-u user

This option sets the setuid to user after completing privileged operations, such as creating sockets that listen on privileged ports.

NOTE:

On Linux, named uses the kernel’s capability mechanism to drop all root privileges except the ability to bind to a privileged port and set process resource limits. Unfortunately, this means that the -u option only works when named is run on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since previous kernels did not allow privileges to be retained after setuid.

-v

This option reports the version number and exits.

-V

This option reports the version number, build options, supported cryptographics algorithms, and exits.

-X lock-file

This option acquires a lock on the specified file at runtime; this helps to prevent duplicate named instances from running simultaneously. Use of this option overrides the lock-file option in named.conf. If set to none, the lock file check is disabled.

Signals

In routine operation, signals should not be used to control the nameserver; rndc should be used instead.

SIGHUP

This signal forces a reload of the server.

SIGINT, SIGTERM

These signals shut down the server.

The result of sending any other signals to the server is undefined.

Configuration

The named configuration file is too complex to describe in detail here. A complete description is provided in the BIND 9 Administrator Reference Manual.

named inherits the umask (file creation mode mask) from the parent process. If files created by named, such as journal files, need to have custom permissions, the umask should be set explicitly in the script used to start the named process.

Files

/etc/named.conf

The default configuration file.

/run/named.pid

The default process-id file.

Notes

Red Hat SELinux BIND Security Profile:

By default, Red Hat ships BIND with the most secure SELinux policy that will not prevent normal BIND operation and will prevent exploitation of all known BIND security vulnerabilities . See the selinux(8) man page for information about SElinux.

It is not necessary to run named in a chroot environment if the Red Hat SELinux policy for named is enabled. When enabled, this policy is far more secure than a chroot environment. Users are recommended to enable SELinux and remove the bind-chroot package.

With this extra security comes some restrictions:

By default, the SELinux policy does not allow named to write any master zone database files. Only the root user may create files in the $ROOTDIR/var/named zone database file directory (the options { «directory» } option), where $ROOTDIR is set in /etc/sysconfig/named.

The «named» group must be granted read privelege to these files in order for named to be enabled to read them.

Any file created in the zone database file directory is automatically assigned the SELinux file context named_zone_t .

By default, SELinux prevents any role from modifying named_zone_t files; this means that files in the zone database directory cannot be modified by dynamic DNS (DDNS) updates or zone transfers.

The Red Hat BIND distribution and SELinux policy creates three directories where named is allowed to create and modify files: /var/named/slaves, /var/named/dynamic /var/named/data. By placing files you want named to modify, such as slave or DDNS updateable zone files and database / statistics dump files in these directories, named will work normally and no further operator action is required. Files in these directories are automatically assigned the ‘named_cache_t‘ file context, which SELinux allows named to write.

See Also

RFC 1033, RFC 1034, RFC 1035, named-checkconf(8), named-checkzone(8), rndc(8), named.conf(5), BIND 9 Administrator Reference Manual.

Copyright

2023, Internet Systems Consortium

Referenced By

ddns-confgen(8), delv(1), dig(1), dnstap-read(1), dnsviz-probe(1), gethostbyname(3), getnameinfo(3), host(1), host.conf(5), hostname(7), hosts(5), in.rlogind(8), in.rshd(8), named-checkconf(1), named-checkzone(1), named-compilezone(1), named.conf(5), named-journalprint(1), named-rrchecker(1), named_selinux(8), nsdiff(1), nslookup(1), nsupdate(1), opendkim-genzone(8), pmdabind2(1), pmdanamed(1), resolv.conf(5), resolvconf.conf(5), resolvconf.openresolv(8), resolver(3), rndc(8), rndc-confgen(8), rollerd(1), tsig-keygen(8).

9.19.12 BIND 9

3.1.7. Примеры настроек программы named и описания зон

В данном разделе мы рассмотрим наиболее типичные, на мой взгляд, примеры построения сервиса доменных имен:

  • описание простой «прямой» и «обратной» зон в домене ru;
  • описание «прямой» и «обратной» зон для поддомена, определенного на двух подсетях;
  • делегирование поддоменов внутри домена.

Этот перечень можно было бы и расширить, но такое расширение будет просто комбинацией приведенных выше случаев. Более сложные случаи встречаются в практике администраторов больших сетей, и для них можно только порекомендовать обращаться за помощью к другим администраторам или разработчикам программ-серверов.

С первой ситуацией сталкивается любая организация, которая намеривается получить свой собственный домен в домене ru. О том, как его получить рассказывалось в разделе 3.1.3. В настоящее время практически нет сетей класса B, поэтому организации получают сети класса C на 254 машины и на основе этих сетей организовывают свой домен. В самом начале такой домен, как правило состоит из одной единственной зоны. В качестве главной машины в этом домене выступает один единственный компьютер с операционной системой Unix или Windows NT. Все остальные варианты рассматривать не будем в силу их неготовности для полноценной работы с сервисом доменных имен Internet. Этот компьютер одновременно является и шлюзом между локальной сетью и сетью Internet-провайдера.

Второй случай касается ситуации, когда сеть учреждения приходится разбивать на подсети. При этом на нескольких подсетях может быть определена одна и та же зона общего домена организации. Такая ситуация часто возникает при постоянных перемещениях подразделений из одного помещения в другое или даже из одного здания в другое. При этом часто подразделения либо съезжаются, либо разъезжаются. Случай типичный для растущей или стареющей организации.

Третий случай обусловлен развитием и усложнением сети или структуры организации, которую данная сеть обслуживает. Когда становится трудно управлять из одного места всеми машинами в домене, права управления частями домена делегируют туда, где изменения наиболее часты. В этом случае администратор домена снимает с себя часть обязательств по управлению доменом и передает их администраторам поддоменов. Для больших организаций — это типичный способ обеспечения сервиса доменных имен. Можно, конечно, спорить о достоинствах или недостатках такого делегирования прав, но в современных условиях это единственная возможность управлять большими разнородными сетями.

3.1.7.1. Небольшой поддомен в домене ru

В данном случае организация получила домен в домене ru и зарегистрировала его в РосНИИРОС. Primary сервер доменных имен установлен на шлюзе 194.226.43.1. Это единственная машина в сети, которая работает под управлением Unix. Все остальные машины — это персональные компьютеры сотрудников. В общем виде схему такого домена можно представить в виде рисунка 3.13:

Рис. 3.13. Структура простой локальной сети

Домен, который зарегистрировала данная организация, пусть будет называться vega.ru. Так как это домен второго уровня, то он должен иметь как минимум два сервера доменных имен: primary и secondary. Основной сервер, primary, установлен на машине-шлюзе, на размещение вторичного получено разрешение от администратора сервера ns.rekarn.ru, который расположен в другой сети, имеющей свой собственный выход в Internet.

Программа named, установленная на машине шлюзе будет иметь следующую конфигурацию, которая задается файлом named.boot:

;
;       Zone vega.ru data base files.
;
directory                                  /etc/namedb
primary       vega.ru                      vega.ru
primary       127.in-addr.arpa             localhost
primary       43.226.194.in-addr.arpa      vega.rev
forwarders    144.206.136.1   144.206.130.137
cаche         .                       named.root

В этом файле определено, что директория расположения описания файлов зоны vega.ru — /etc/namedb. Это стандартная директория для операционной системы FreeBSD. Файла описания «прямой» зоны домена vega.ru — файл vega.ru будет размещен в этой директории (/etc/namedb/vega.ru). Кроме «прямой» зоны описаны еще две «обратных» зоны 127.in-adrr.arpa и 43.226.194.in-addr.arpa. Первая определяет обратное соответствие между адресом 127.0.0.1 и именем localhost, а вторая множество обратных соответствий для сети 194.226.43.0. Последним указан файл начальной загрузки cache. Символ «.» в качестве первого аргумента указывает на описание домена root.

Кроме этого команда forwarders указывает IP-адреса серверов доменных имен, к которым следует обращаться в случае невозможности самостоятельно получить адрес. Это сделано для того, чтобы в начальный период функционирования сервера он мог отвечать на запросы клиентов из данной зоны, хотя сам он еще и не зарегистрирован в корневом сервере домена ru.

В принципе, можно было бы просто указать данные сервера в настройках resolver для машин данного домена, но зато потом везде нужно было бы их снова менять. Использование forwarders позволяет после регистрации домена и размещения серверов не перестраивать настройки всех компьютеров в домене. Кроме того, named сразу начинает работать как интеллектуальный кэширующий сервер, что при частом обращении к одним и тем же именам позволяет быстро получать IP-адреса или имена машин.

Файл описания «прямой» зоны для домена vega.ru будет выглядеть следующим образом (/etc/namedb/vega.ru):

@         IN    SOA     vega-gw.vega.ru paul.vega.ru (
                        101             ;serial number
                        86400           ;refresh
                        3600            ;retry
                        3888000 ;expire
                        99999999        ;minimum
                        )
;       Name server
          IN    NS              vega-gw.vega.ru.
          IN    NS              ns.relarn.ru.
          IN    NS              polyn.net.kiae.su.
          IN    A               194.226.43.1
          IN    MX      0       vega-gw.vega.ru.
          IN    MX      10      ns.relarn.ru.
;
localhost       IN      A               127.0.0.1
;
vega-gw   IN    A               194.226.43.1
          IN    MX      0       vega-gw
          IN    MX      10      ns.relarn.ru.
www       IN    CNAME           vega-gw
ftp       IN    CNAME           vega-gw
gopher    IN    CNAME           vega-gw
;
dos1      IN    A               194.226.43.2
dos2      IN    A               194.226.43.3
; The rest of net should be presented below.

Запись SOA берет имя зоны из записи primary файла named.boot (символ «@»). В качестве машины, на которой установлен сервер, указана машина vega-gw.vega.ru, а в качестве администратора — paul@kiae.su. Остальные поля установлены в соответствии с описанием записи SOA.

Обратите внимание на следующее обстоятельство: имя текущей зоны будет взято из команды primary файла named.boot и использоваться для описания зоны, только в том случае если в записи SOA будет указан символ коммерческого «@». Например, в следующем примере могут возникнуть проблемы с описанием зоны:

          IN   SOA     vega-gw.vega.ru paul.vega.ru (
                            101             ;serial number
                            86400           ;refresh
                            3600            ;retry
                            3888000 ;expire
                            99999999        ;minimum
                            )
;       Name server
         IN   NS              vega-gw.vega.ru.
         IN   NS              ns.relarn.ru.
         IN   NS              polyn.net.kiae.su.
         IN   A               194.226.43.1
         IN   MX      0       vega-gw.vega.ru.
         IN   MX      10      ns.relarn.ru.

Ни NS-записи, ни A-запись, ни MX-записи не привязаны к конкретному домену, и следовательно не используются named.

Две NS-записи определяют три машины в качестве сервера доменных имен для данной зоны: vega-gw.vega.ru, ns.relarn.ru и polyn.net.kiae.su. Первая запись типа A определяет адрес всего домена для обслуживания неполных запросов. Следующие две записи MX определяют правила пересылки почты на домен по адресам типа user@vega.ru.

За описанием зоны в нашем файле следует описание «петли», т.е. имени для адреса 127.0.0.1. В FAQ по сервису доменных имен можно найти и другие решения, но в большинстве случаев, обычно, рекомендуется определять имя localhost как localhost.domain.name, или в нашем случае — localhost.vega.ru.

Первой в домене описана машина-шлюз. На ней установлены сервисы World Wide Web, FTP и Gopher. Для каждого из них определены имена, которые должны облегчить запоминание доменного имени сервера. После записей CNAME идут записи описания других машин зоны. Так как это обычные рабочие места под управлением MS-DOS и Widows, то никаких дополнительных записей для их описания не требуется.

Как утверждается во всех руководствах по DNS, описание обратных зон для домена не является обязательным, но крайне желательно. Для нашего простого домена в файле named.boot описаны две обратные зоны: 127.in-addr.arpa и 43.226.194.in-addr.arpa.

Зона 127.in-addr.arpa описывает обратное соответствие межу адресом 127.0.0.1 и именем lo-calhost.vega.ru. Описание зоны будет располагаться в файле /etc/namedb/localhost:

@                       IN      SOA     vega-gw.vega.ru paul.vega.ru (
                                        101             ;serial number
                                        86400           ;refresh
                                        3600            ;retry
                                        3888000 ;expire
                                        99999999        ;minimum
                                        )
;       Localhost declaration
1                       IN      PTR     localhost.vega.ru.

В данном случае имя зоны также, как и в предыдущем случае берется из команды primary файла named.boot:

primary    127.in-addr.arpa             localhost

Согласно этому описанию символ «@» заменяется на имя 127.in-addr.arpa, которое и добавляется к цифре 1, образуя имя 1.127.in-addr.arpa. Так как сеть 127.0.0.0 — это сеть класса А, то адрес 127.1 эквивалентен адресу 127.0.0.1.

Вторая «обратная» зона описывает все остальные IP-адреса и размещается в файле /etc/namedb/vega.rev:

@         IN   SOA   vega-gw.vega.ru paul.vega.ru (
                     101             ;serial number
                     86400           ;refresh
                     3600            ;retry
                     3888000 ;expire
                     99999999        ;minimum
                     )
          IN   NS    vega-gw.vega.ru.
          IN   NS    ns.relarn.ru.
          IN   NS    polyn.net.kiae.su.
;       Reverse zone description.
1         IN   PTR   vega-gw.vega.ru.
2         IN   PTR   dos1.vega.ru.
3         IN   PTR   dos2.vega.ru.
; description of the other hosts should be placed below.
;

Первые две NS-записи в этом примере определяют сервера доменных имен для этой зоны. Так как «прямая» зона это зона второго уровня в домене ru, то будет логичным и для «обратной» зоны разместить дублирующий сервер в том же месте, что и дублирующий сервер для «прямой» зоны. Имя зоны берется из команды primary файла named.boot:

primary      43.226.194.in-addr.arpa vega.rev

Таким образом к единичке, указанной в записи PTR для машины vega-gw.vega.ru будет получено «обратное» имя 1.43.226.194.in-addr.arpa.

Все имена машин в поле данных записей типа PTR должны обязательно заканчиваться точкой, иначе они будут расширены именем зоны.

И последний файл, который необходим для запуска сервера доменных имен, — это файл начальной загрузки named, определенный в команде cache файла named.boot. В нашем случае этот файл имеет полное имя — /etc/namedb/named.root. Содержание этого файла приведено в примере 5. Файл просто копируется с сервера ftp.internic.net. В ряде случаев провайдеры рекомендуют пользоваться их файлом начальной загрузки, а не стандартным.

3.1.7.2. Описание «прямой» и «обратной» зон для поддомена определенного на двух подсетях

В данном примере мы рассмотрим описание домена третьего уровня polyn.kiae.su, который определен на двух подсетях сети 144.206.0.0: 144.206.160.0 и 144.206.192.0. Если в предыдущем случае мы выделяли две «обратные» зоны из-за особой роли адреса 127.0.0.1, то в данном случае нам придется выделить «обратные» зоны на каждую из подсетей. Кроме того этот сервер мы также будем использовать в качестве дублирующего для домена vega.ru. Файл named.boot в этом случае будет иметь вид:

;
;       Zone polyn.kiae.su - data base files.
;
directory                                            /etc/namedb
primary      polyn.kiae.su                           polyn.kiae.su
primary      127.in-addr.arpa                        localhost
primary      160.206.144.in-add.arpa                 polyn
primary      192.206.144.in-addr.arpa                quest
secondary    vega.ru 194.226.43.1                    vega.ru
secondary    43.226.194.in-addr.arpa 194.226.43.1    vega.rev
forwarders   144.206.136.1   144.206.130.3
cаche        .                                       named.root

Как видно из содержания этого файла все файлы описания зоны расположены в директории /etc/namedb (команда directory), описание зоны polyn.kiae.su находится в файле /etc/namedb/polyn.kiae.su, описание зоны 127.in-addr.arpa — в файле /etc/namedb/localhost, описание зоны 160.206.144.in-addr.arpa — в файле /etc/namedb/polyn, описание зоны 192.206.144.in-addr.arpa — в файле /etc/namedb/quest. Кроме этого, после запуска, данный сервер опрашивает primary сервер зоны vega.ru и копирует с него зоны vega.ru и 43.226.194.in-addr.arpa. Первую в файл /etc/namedb/vega.ru, а вторую в файл /etc/namedb/vega.rev. Перейдем теперь к описанию файлов зоны polyn.kiae.su.

;
;       Zone -- polyn.kiae.su
$ORIGIN kiae.su.
polyn      IN   SOA  polyn.net.kiae.su. paul.kiae.su. (
           36 3600 300 9999999 3600 )
;
           IN   NS   polyn.net.kiae.su.
           IN   NS   ns.kiae.su.
           IN   A    144.206.160.32
           IN   MX   0       ns.polyn.kiae.su.
           IN   MX   10      relay.net.kiae.su.
$ORIGIN net.kiae.su.
polyn      IN   A    144.206.130.137
$ORIGIN kiae.su.
ns         IN   A    144.206.130.3
$ORIGIN polyn.kiae.su.
*          IN   MX   2       ns.polyn.kiae.su.
           IN   MX   10      relay.net.kiae.su.
;
ns         IN   A    144.206.160.32
www        IN   CNAME   ns.polyn.kiae.su.
ftp        IN   CNAME   ns.polyn.kiae.su.
;
kurm       IN   A    144.206.160.50
           IN   MX   0 kurm.polyn.kiae.su.
           IN   MX   10 polyn.net.kiae.su.
           IN   MX   20 relay.net.kiae.su.
driver     IN   A    144.206.160.51
lebedev    IN   A    144.206.160.41
;
georg      IN   A    144.206.192.5
olga       IN   A    144.206.192.2
           IN   MX   0 olga.polyn.kiae.su.
           IN   MX   10 polyn.net.kiae.su.
           IN   MX   20 relay.net.kiae.su.
nata       IN   A    144.206.192.3
kaverin    IN   A    144.206.192.6
temp       IN   A    144.206.192.254
; The rest of zone is placed below
........

Данный пример интересен тем, что в нем наглядно продемонстрировано использование «приклеенных» A-записей.

Начинается домен также, как и в предыдущем примере — с записи SOA. В данном случае зона описывается непосредственно командой $ORIGIN. В записи SOA указано имя домена без точки на конце, что означает, что оно будет расширено именем kiae.su. Следующие две записи определяют серверы доменных имен для данного домена. Но эти серверы расположены в другой зоне. В принципе named способен найти их IP-адреса, но из соображений большей надежности эти две записи сопровождаются «приклеенными» записями. При чем для каждого из серверов определяется домен (команда $ORIGIN) и за тем имя и IP-адрес по записи A. Наличие данных блоков записей заставляет администратора снова определить в качестве текущего домена домен polyn.kiae.su. После этого следует блок записей для которых указан в качестве имени символ «*». Дело в том, что в данной подсети существует несколько машин, которые поддерживают почтовые ящики пользователей, поэтому записи MX при этом символе определяют порядок прохождения почтовых сообщений внутрь домена.

Первая машина домена — ns.polyn.kiae.su. Фактически, это тоже «приклеенная» запись, т.к. это имя уже встречалось раньше. В след за ним определено несколько записей CNAME. Исторически сложилось так, что во многих страницах World Wide Web ссылки стоят на polyn.net.kiae.su, поэтому это имя также должно быть сохранено, но в новых редакциях используется синоним www.polyn.kiae.su.

Далее в домене есть две машины, которые являются почтовыми серверами для пользователей этого домена: kurm и olga.

Файлов «обратных» зон в данном случае определено два: 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa. Сделано это из-за того, что в данном случае домен определен на двух различных подсетях сети класса B. В принципе, если бы в данный домен были выделены машины не всей подсети, а только ее частей, то для адресов 144.206.160.0, 144.206.161.0, 144.206.162.0 и т.д. до 144.206.192.0 следует описывать «обратные» зоны. При этом каждую из них надо прописывать и в домене старшего уровня, которым в данном случае является 206.144.in-addr.arpa. Рассмотрим примеры описания этих доменов:

$ORIGIN 206.144.in-addr.arpa.
160       IN    SOA     kiae-gw.kiae.su. root.kiae-gw.kiae.su. (
          22 3600 300 9999999 3600 )
          IN    NS      polyn.net.kiae.su.
$ORIGIN net.kiae.su.
polyn     IN    A       144.206.160.32
          IN    A       144.206.130.137
$ORIGIN 206.144.in-addr.arpa.
160       IN    NS      ns.kiae.su.
$ORIGIN kiae.su.
ns        IN    A       144.206.130.3
$ORIGIN 160.206.144.in-addr.arpa.
53        IN    PTR     lenya.polyn.kiae.su.
40        IN    PTR     apollo.polyn.kiae.su.
54        IN    PTR     kagan.polyn.kiae.su.
; The rest of the domain should be placed below

Данный файл начинается также, как и описание «прямой» зоны, в нем присутствуют те же «приклеенные» записи для описания серверов доменных имен. Это обстоятельство заставляет снова вводить команды $ORIGIN. Весь остаток файла состоит только из записей типа PTR.

Аналогично выглядит и файл 192.206.144.in-addr.arpa:

$ORIGIN 206.144.in-addr.arpa.
192    IN    SOA     kiae-gw.kiae.su. root.kiae-gw.kiae.su. (
       23 3600 300 9999999 3600 )
       IN    NS      polyn.net.kiae.su.
$ORIGIN net.kiae.su.
polyn  IN    A       144.206.160.32
       IN    A       144.206.130.137
$ORIGIN 206.144.in-addr.arpa.
192    IN    NS      ns.kiae.su.
$ORIGIN kiae.su.
ns     IN    A       144.206.130.3
$ORIGIN 192.206.144.in-addr.arpa.
6      IN    PTR     kaverin.polyn.kiae.su.
7      IN    PTR     kost.polyn.kiae.su.
1      IN    PTR     quest.polyn.kiae.su.
33     IN    PTR     vovka.polyn.kiae.su.
2      IN    PTR     olga.polyn.kiae.su.
34     IN    PTR     paul.polyn.kiae.su.
3      IN    PTR     nata.polyn.kiae.su.
254    IN    PTR     temp.polyn.kiae.su.
4      IN    PTR     demin.polyn.kiae.su.
5      IN    PTR     georg.polyn.kiae.su.

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

3.1.7.3. Делегирование поддомена внутри домена

Рассмотрим последний пример — делегирование поддомена внутри домена. Данная ситуация возникает в том случае, когда организация растет и обслуживание всего домена становится довольно трудоемкой задачей. Собственно, проблема возникает как с администрированием — слишком много машин и пользователей, так и со скоростью ответа на запросы — слишком много запросов к одному серверу, что плохо сказывается на его реактивности.

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

Рассмотрим такое делегирование на следующем примере: в домене kiae.su делегируется зона kiae.su. Пример описания этой зоны мы рассматривали в предыдущем примере. Поэтому в данном примере мы рассмотрим только описание зоны kiae.su и только записи касающиеся поддомена polyn.kiae.su, т.к. полное описание домена будет занимать 23 страницы.

Пример делегирования зоны:

$ORIGIN su.
kiae        IN   SOA  ns.kiae.su. noc.relcom.eu.net. (
            3000302 28800 3600 3600000 86400 )
            IN   NS   ns.kiae.su.
; List of NS records and MX records for domen kiae.su.
......
$ORIGIN kiae.su.
hytelnet    IN   A    193.125.152.10
gopher      IN   A    193.125.152.10
archie      IN   A    193.125.152.10
$ORIGIN net.kiae.su.
polyn       IN   A    144.206.130.137
            IN   A    144.206.160.32
; Other records
...
polyn       IN   NS   polyn.net.kiae.su.
; The rest of the description of the descriptionkiae.su zone.
.....

В данном примере следует обратить внимание на следующие особенности описания. Во-первых, при описании сервисов hytelnet, goher и archie не используется записи типа CNAME. Для всех этих доменных имен указан один и тот же IP-адрес. Во-второых, при описании делегированной зоны сначала указана запись типа A для машины polyn.net.kiae.su. Это primary сервер зоны polyn.kiae.su. Для этой же зоны могут быть также указаны и secondary серверы данной зоны. Как видно из описания машины polyn.net.kiae.su, ей соответствует два IP-адреса. В данном случае это не адреса синонимы на одном и том же порте, а адреса разных интерфейсов данной машины, т.к. она является шлюзом локальной подсети.

Приведенного выше описания достаточно для того, чтобы при помощи нерекурсивных опросов серверов, resolver или сервер нашли нужный IP-адрес.

«Обратная» зона прописывается точно также. Это значит, что зона 160.206.144.in-addr.arpa должна быть прописана в зоне 206.144.in-addr.arpa. Термин «прописать» означает выполнение следующих операций: в зоне должна быть определена подзона и машина-сервер этой подзоны, т.е. указана «приклеенная» запись для этой машины, в зоне должна быть указана запись типа NS для выделяемой подзоны.

В домене vega.ru сервер зоны определялся в самой зоне vega.ru, в случае с зоной polyn.kiae.su, сервер расположен в другом домене — net.kiae.su. Однако это не мешает управлять зоной. В принципе, используя команды $ORIGIN можно опредлить зоны внутри домена и в том же файле, что и описание самого домена. Собственно в нашем примере так оно и сделано: домен net.kiae.su определен в файле описания домена kiae.su.

Теперь от примеров описания зон перейдем к средствам контроля за размещенными зонами.

3.1.8. Программа nslookup

Описать зону — это только полдела. После установки следует убедиться, что все работает нормально. Другой случай, когда необходим контроль за работой сервера DNS — жалобы пользователей. При этом смотреть свои собственные файлы дело бесполезное, т.к. в них скорее всего ошибок нет, т.к. сервер эксплуатируется уже некоторое время. Едиственный способ убедиться в том, что все работает так, как надо — проиметировать работу системы, взаимодействующей с сервером. Именно эту задачу и решает программа nslookup.

Программа может использоваться в интерактивном режиме и в режиме генерации отчета о разовом запросе. Наиболее часто используют интерактивный способ тестирования. Для интерактивного тестирования достаточно просто вызвать программу по имени при этом в качестве сервера будет взят сервер, указанный в файле конфигурации resolver:

/usr/paul>nslookup
> 144.206.192.1
Server:         arch.kiae.su
Address:        144.206.136.10
Name:           quest.polyn.kiae.su
Address:        144.206.192.1
>exit

В данном конкретном примере цель запроса состояла в получении имени машины по ее IP-адресу. Возможна и обратная операция, т.е. получение IP-адреса по имени:

/usr/paul>nslookup
> polyn.net.kiae.su
Server:         arch.kiae.su
Address:        144.206.136.10
....
Address:        144.206.192.1
>exit

Однако, тестирование имен с локального сервера только проверяет как resolver работает с этим локальным сервером. Для того, чтобы проверить, как имена вашего домена разрешаются с другого сервера доменных имен, следует изменить текущий сервер доменных имен, используемый nslookup в качестве первого при разрешении доменного имени:

> server vega.ru
Default Server:  vega.ru
Address:  194.226.43.1
>

В данном случае в качестве текущего сервера выбран сервер vega.ru. После изменения адреса текущего сервера можно снова проверить адреса имен вашего домена на доступность для сервиса доменных имен.

При помощи nslookup можно посмотреть содержание записей базы данных описания зоны. Делается это несколькими способами. Первый из них — это установка типа записей:

> set querytypa=SOA
> polyn.kiae.su
Server:  vega.ru
Address:  194.226.43.1
polyn.kiae.su
        origin = polyn.net.kiae.su
        mail addr = paul.kiae.su
        serial  = 36
        refresh = 3600 (1 hour)
        retry   = 300 (5 mins)
        expire  = 9999999 (115 days 17 hours 46 mins 39 secs)
        minimum ttl = 3600 (1 hour)
polyn.kiae.su   nameserver = polyn.net.kiae.su
polyn.kiae.su   nameserver = ns.kiae.su
>

В данном случае установлен тип записи для просмотра — SOA, после этого задано имя polyn.kiae.su. В этовет на этот запрос сервер нашел другой сервер, в зону ответственности которого входит данное имя и распечатал запись SOA для этой зоны. При этом все поля распечатываются в понятном для чтения виде.

Другой способ заключается в том, чтобы исполбзовать команду ls:

>ls -t soa polyn.kiae.su
.... список записей зоны .....
>

Если необходимо проконтролировать работу сервера и resolver, то в этом случае имеет смысл включить режим отладки — debug:

> set debug
> 1.192.206.144.in-addr.arpa.
Server:  ns.kiae.su
Address:  144.206.130.3
------------
Got answer:
  HEADER:
    opcode = QUERY, id = 20, rcode = NOERROR
    header flags:  response, auth. answer, want recursion, recursion avail.
    questions = 1,  answers = 1,  authority records = 0,  additional = 0
  QUESTIONS:
    1.192.206.144.in-addr.arpa, type = ANY, class = IN
  ANSWERS:
  ->  1.192.206.144.in-addr.arpa
    name = quest.polyn.kiae.su
    ttl = 3600 (1 hour)
------------
1.192.206.144.in-addr.arpa
    name = quest.polyn.kiae.su
    ttl = 3600 (1 hour)
>

В данном случае запрашивается имя по «обратному» запросу. Программа транслирует сам запрос и способ его исполнения. Для более сложных запросов трасса может составлять несколько экранов.

3.1.9. DNS и безопасность

В сентябре 1996 года многие компьютерные издания Москвы опубликовали материал, в котором рассматривался случай подмены доменных адресов World Wide Web сервера агенства InfoART, что привело к тому, что подписчики этого сервиса в течении некоторого времени вместо страниц этого агенста просматривали картинки «для взрослых».

Администрирование DNS осуществляла компания Demos, поэтому пресс-конферению по поводу этого случая Demos и InfoArt проводили совместно. Разъяснения провайдера главным образом свелись к тому, что в базе данных DNS самого Demos никаких изменений не проводилось, а за состояние баз данных secondary серверов Demos ответственности не несет. Почему такое заявление вполне оправдывает провайдера?

Как было указано раньше, обслуживание запросов на получение IP-адресов по доменным именам, а именно об этом идет речь в случае InfoArt, осуществляется не одним сервером доменных имен, а множеством серверов. Все secondary серверы копируют базу данных с primary сервера, но делают они это с достаточно большими интервалами, иногда не чаще одного раза в двое суток. Запрос разрешает тот сервер, который быстрее откликается на запрос клиента. Таким образом, если подправить информацию на secondary сервере о базе данных primary сервера, то можно действительно на время между копированиями описания зоны заставить пользователей смотреть совсем не то, что нужно. Таким образом, практически все провайдеры попадают в категорию неблагонадежных. Но провайдеры также могут оказаться не при чем. В принципе, любой администратор может запустить у себя на машине named и скопировать зону с primary сервера, не регистрируя ее в центре управления сетью. Это обычная практика, т.к. разрешение имен — главный тормоз при доступе к удаленной машине, и часто по timeout прерывается работа с ресурсом из-за невозможности быстрого разрешения имени. Таким образом, все администраторы сети попадают в потенциальных злоумышленников. Но на самом деле существуют еще и другие способы. Например, кэш re-solver или сервера имен. Если время хранения записи в кэше большое, то сервер или resolver не будут обращаться к удаленному серверу вообще, а будут брать записи из кэша. Вмешаться в структуру данных кэша также возможно, а это значит, что можно и увеличить время хранения записи. Если организация- подписчик пользуется для доступа в сеть proxy-сервером, а это также обычная практика, то достаточно поправить кэш этого proxy и все пользователи этой организации будут ходить туда, куда их направит поправленная запись.

Существует несколько способов ограничения этого произвола. Первый из них — это точное знание IP-адресов ресурсов. В этом случае можно проверить состояние ресурса и выявить причину ошибки. Второй сопособ, запретить копировать описание зоны кому не поподя. Современные программы named позволяют описывать IP-адреса сетей, из которых можно копировать зоны. Правда такая политика должна быть согласована с другими владельцами зоны, в противном случае зону скопируют с secondary сервера. И наиболее мягкое средство — уменьшение времени хранения записей в кэше.

Для защиты можно использовать и фильтрацию пакетов. Зоны раздаются только по 53 порту TCP, в отличии от простых запросов. Если определить правила работы по этому порту, используя межсетевой фильтр, то можно и ограничить произвол при копировании информации с сервера доменных имен. Вообще, не стоит относиться к сервиру доменных имен легкомысленно. Следует учитывать тот факт, что используя этот сервис, можно выявить структуру вашей локальной сети.

Назад |
Содержание |
Вперед

Понравилась статья? Поделить с друзьями:
  • Лекарство эналаприл инструкция по применению цена отзывы аналоги цена
  • Мелатонин инструкция цена в аптеках новосибирска
  • Руководство по gta online
  • Пароконвектомат электролюкс инструкция на русском языке
  • После утверждения руководством