Сервис доменных имен

Часть 1. Сердце сервиса доменных имен - программа named

Ядром системы доменных имен, о принципах построения которой было рассказано в предыдущем выпуске "Открытых Систем Сегодня" (#24(66)), является программа-сервер доменных имен. В большинстве случаев в качестве такого сервера выступает программа named. Именно о ней и пойдет речь в данной статье.

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

Программа named - один из самых популярных серверов доменных имен из тех, что применяются в Internet. Для ее работы используются 53-ие порты TCP и UDP.

При разработке named была реализована концепция функционирования трех типов серверов доменных имен: primary, secondary, cache. Если быть более точным, named может одновременно выполнять функции всех трех типов серверов.

Primary server - это основной сервер зоны¹. В его базе данных описывается соответствие доменных имен и IP-адресов для машин, принадлежащих данной зоне. База данных сервера хранится на том же компьютере, где функционирует сервер доменных имен. При запуске сервера последний обращается к файлам своей базы данных, после чего он получает возможность обслуживать запросы на разрешение доменных имен IP-адресами и обратно.

Secondary server - это дублирующий сервер зоны. Он также способен отвечать на запросы прикладных программ и других серверов, требующих разрешения доменных имен IP-адресами и/или наоборот, как и primary server. Главное отличие от primary server заключается в том, что secondary server не имеет своей базы данных зоны, а копирует ее с primary server в момент запуска, и затем заботится о поддержке соответствия между копией базы данных и базой данных primary server в соответствии с настройками последнего.

Cache server - это сервер, который запоминает в своем буфере (cache) соответствия между именами и IP-адресами и хранит их некоторое время. Если вы достаточно часто обращаетесь к каким-либо ресурсам сети, то в случае использования cache-сервера вы всегда будете быстро получать IP-адрес или доменное имя, так как его прикладное программное обеспечение будет пользоваться услугами cache-сервера. При этом обращение к местному серверу зоны, корневому серверу и удаленным серверам зон будет осуществляться только один раз - в момент первого обращения к ресурсу.

Для организации зоны (домена) необходимо иметь primary server² и как минимум один secondary server. Если с primary server все более или менее понятно (он создается на компьютере, который входит в описываемый домен и управляется администратором домена), то размещение secondary server всегда вызывает определенные трудности. Его можно создать на другом компьютере домена и тем самым формально выполнить условия по организации двух серверов доменных имен для одной зоны³. Но в этом решении есть два нюанса. Во-первых, организация второго сервера доменных имен заставляет устанавливать либо еще одну Unix-машину, либо Windows NT, в которых есть поддержка BIND. Во-вторых, с точки зрения надежности secondary server лучше всего размещать у провайдера, так как обычно именно он делегирует зону из своего домена, и через его сервер доменных имен по рекурсивной или нерекурсивной процедуре разрешения имени весь остальной мир получает доступ к машинам вашего домена.

Если же домен распределен по нескольким сетям или подсетям, которые к тому же и территориально расположены в разных зданиях, различных частях города или даже в разных городах, то тогда для каждой из этих частей домена следует организовать secondary server, что не отменяет размещения secondary server у провайдеров, поддерживающих такую распределенную систему.

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

О второй Unix-машине или Windows-NT я упомянул из тех соображений, что многие маленькие локальные сети строятся по схеме, в которой многозадачная и многопользовательская операционная система ставится только на машине-шлюзе, через которую локальная сеть подключается к сети провайдера. На всех остальных машинах устанавливается либо Windows 95, либо MS-DOS, одним словом, персональная операционная система.

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

Любой сервер является кэширующим. И primary-, и secondary-серверы запоминают на некоторое время в своем буфере (cache) соответствие между именами и IP-адресами любой зоны, если к ней хоть раз обращались и была выполнена процедура разрешения адреса. Это позволяет сократить обмен запросами между серверами и обеспечить более быстрое разрешение адреса для часто используемых ресурсов.

Организация на базе named только кэширующего сервера основана на том предположении, что primary- и secondary-серверы зоны могут быть перегружены запросами (типичный случай для большой организации). В этих условиях время на разрешение имени может быть довольно значительным. Кэширующий сервер на вашей вычислительной установке позволит несколько сократить это время, если вы постоянно обращаетесь к одним и тем же хостам. Ждать придется только при первом обращении, когда будет выполняться стандартная процедура разрешения адреса. Все последующие обращения будут обрабатываться вашим кэширующим сервером.

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

От общего описания типов серверов, которые можно организовать при помощи программы named, перейдем к файлам ее настройки.

Файлы настройки named

Программа named управляется через файлы настройки. Они нужны для того, чтобы в момент старта named могла найти другие серверы доменных имен, root-серверы, например, загрузить описание своей зоны, скопировать зону с primary server и т.п.

Всего существует три типа файлов настройки программы named, или, как их еще называют, базы данных домена. К ним относятся:

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

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

Файл описания базы данных - named.boot

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

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

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

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

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

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

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

Листинг 1.

; Пример файла named.boot
; строки начинающиеся с символа `;`
; воспринимаются программой
; named как комментарии

directory /etc/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
secondary 160.206.144.
                 in-addr.arpa
                 144.206.130.137
                 144.206.192.34
cache . named.root

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

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

Описание места размещения файлов базы данных

Команда directory определяет каталог namedb как директорию размещения файлов базы данных named. В сущности, вовсе не обязательно размещать все файлы в одной директории. Можно создать несколько директорий, например, по количеству зон. Christophe Wolfhugel (Christophe Wolfhugel@ grasp.insa-lyon.fr), в частности, для каждой зоны использует отдельную поддиректорию в корневой директории named.

Корнем описания файлов базы данных 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 используется для указания зоны, для которой данный сервер выступает как primary-сервер, и указания имени файла, описывающего эту зону. Формат команды primary можно охарактеризовать следующим образом:

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

В примерах 1 и 2 используется три команды 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 это смущать не должно. Использование имен зон в качестве имен файлов - это общепринятая практика. Так гораздо проще ориентироваться среди файлов описания базы данных named.

Часто вместо 0.0.127.in-addr.arpa указывают 127.in-addr.arpa. Сеть 127 - это сеть класса А. Для этой сети что 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 используется при описании зон, для которых данный сервер является secondary-сервером, и имеет следующий формат:

secondary <имя зоны>

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

В наших примерах описано две таких зоны - polyn.kiae.su и 160.206.144.in-addr.arpa. В примерах для каждой из этих зон указано по два IP-адреса серверов, которые описывают ее. В сущности, достаточно указывать адрес только primary-сервера для зоны. С точки зрения актуальности состояния базы данных зоны, для которой создается secondary-сервер, указание одного только primary самое правильное решение, так как только primary-сервер содержит наиболее актуальную базу данных зоны. Однако иногда имеет смысл указать несколько серверов, primary и secondary, например. В этом случае база копируется с того, который указан первым, если он доступен. Если сервер не доступен, то опрашивается следующий в списке, до первого доступного сервера. Подобная практика приводит к тому, что становится довольно трудно уничтожить мертвые адреса. Так, например, за машиной polyn.net.kiae.su одно время было закреплено три IP-адреса. В настоящее время осталось только два. Третий адрес давно вычеркнут из всех primary-серверов, но он тем не менее время от времени появляется при обращении к данной машине.

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

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

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

В самом начале описания named было сказано, что сервис работает по 53 портам UDP и TCP. Для чего в рамках одного и того же сервиса было организовывать информационные магистрали с использованием различных типов транспорта? Дело в том, что обычные запросы на разрешение имен IP-адресами или IP-адресов именами отправляются по транспорту UDP. Это делается из-за того, что объем передаваемой информации небольшой. Но при организации secondary-сервера ситуация меняется. Этот сервер запрашивает другой сервер, прописанный в команде secondary, то есть целиком все описание зоны, а это может быть довольно большой объем информации. Вот в этом случае и используется сервис TCP. Из-за такой архитектуры возникают затруднения как со скоростью обслуживания запросов к системе доменных имен, так и с безопасностью сети вообще.

Скорость DNS - это притча во языцех. При установке больших временных интервалов ожидания ответов отказ на обслуживание приходит только по истечении времени ожидания для данного сервиса UDP. Это если сервис неактивен. Если же сервис активен, то нельзя точно установить, работает он или нет, поскольку сервис UDP - это сервис без установки соединения. Но если говорить о копировании зон, то можно столкнуться со следующей ситуацией: запросы разрешаются, а зоны не копируются. В этом случае, кроме администратора данного сервера, никто помочь не может. Администратор может намеренно запретить копирование зоны, а, возможно, за отведенный интервал времени не удается передать зону, или же во время передачи разрушается TCP-сессия. В российской части Internet такое случается довольно часто. Если вдруг пользователям кажется, что система начинает медленно "умирать", то это может происходить из-за того, что secondary-серверы не могут обновить описания зон, а так как копии могут быть получены в разное время, то и серверы "мрут" в разное время.

Файл начальных настроек named

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

Формат команды выглядит следующим образом:

cache <имя зоны>

<имя файла cache>

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

По данным Крега Ричмонда (Craig Richmond, craig@ecel.uwa. edu.au), различные версии named по-разному используют файл, указанный в команде cache. Одни программы, загрузив данные из этого файла, больше его не используют, другие, наоборот, постоянно вносят в него изменения.

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

Forwarders and slave

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

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

Случай организации рекурсивной процедуры разрешения имени с использованием этой команды был рассмотрен ранее. Однако им не ограничивается круг использования команды forwarders. При регистрации домена некоторое время внешний относительно этого домена мир не подозревает о существовании домена. Должно пройти некоторое время, прежде чем будет закончена процедура регистрации домена и обновления баз данных вышестоящего в иерархии DNS домена на всех серверах, как primary, так и secondary. Однако внутри домена все работает нормально, поскольку сервер запускается до официальной регистрации и способен обслуживать машины домена. Однако он может и не иметь информации обо всех доменах Internet. По этой причине всегда полезно указать команду forwarders на сервер вышестоящего домена. Так, например, для зоны polyn.kiae.su сервером домена kiae.su, в который входит данная зона, является сервер с IP-адресом 144.206.136.1. Для того чтобы пересылать на него запросы на разрешение имен IP-адресами, в named.boot следует включить команду:

forwarders 144.206.136.1

Обычно указывают не один, а несколько 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, будет выглядеть так, как показано в листинге 2.

Листинг 2.

; ПРИМЕР ПОДЧИНЕННГО СЕРВЕРА,
; РАБОТАЮЩЕГО ПО РЕКУРСИВНОЙ
; ПРОЦЕДУРЕ РАЗРЕШЕНИЯ ЗАПРОСОВ
; ОТ RESOLVER
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

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

На этом можно закончить описание файла named.boot и перейти к описанию файлов базы данных named, но об этом в следующий раз.