3.1.6. Программа named
К сожалению достаточно подробной единой документации по 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 в соответствии с настройками последнего.
Caсhe server - это сервер, который запоминает в своем буфере (caсhe) соответствия между именами и IP-адресами и хранит их некоторое время. Если пользователь достаточно часто обращается к каким-либо ресурсам сети, то в случае использования caсhe-сервера он всегда будет быстро получать IP-адрес или доменное имя, т.к. его прикладное программное обеспечение будет пользоваться услугами caсhe-сервера. При этом обращение к местному серверу зоны, корневому серверу и удаленным серверам зон будут осуществляться только один раз - в момент первого обращения к ресурсу.
Для организации зоны (домена) необходимо иметь 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 прейдем к файлам ее настройки.
3.1.6.1. Файлы настройки named
Всего существует три типа файлов настройки программы named, или, как их еще называют, базы данных домена. К ним относятся:
В литературе по named принято начинать с файла описания базы данных named - named.boot
Этот файл named использует для своей настройки и первичной загрузки базы данных домена. Это первое, что ищет named при своем запуске. Если внимательно изучить скрипты начальной загрузки любого Unix, то при запуске сетевых серверов в части, отвечающей за запуск сервера доменных имен, можно увидеть, что в случае отсутствия файла named.boot программа named не будет запущена.
В файле named.boot для описания настроек named используются следующие команды:
Прежде, чем рассматривать примеры файлов named.boot для различных типов серверов, хотелось бы обратить внимание читателя на две последние команды.
Фактически, именно они и определяют какая из процедур разрешения запроса (рекурсивная или нерекурсивная) будут применяться на вашем сервере. Если в файле named.boot есть команда slave, то определена рекурсивная процедура разрешения запроса, т.к. в этом случае named будет отсылать все запросы на серверы указанные в команде forwarders и от них получать адреса или имена удаленных хостов. В этом случае серверы из forwarders будут опрашивать корневые и удаленные серверы доменов. Если эти серверы также содержат команду slave, то поиск адреса или имени будут осуществлять серверы, которые определены в их файлах named.boot как forwarders.
Когда такая конфигурация сервера полезна? На сколько мне известно, обычно так настраивают серверы поддоменов внутри одной организации. В качестве сервера, на который осуществляется пересылка всех запросов, используется сервер всего домена. При этом с корневыми серверами общается только этот сервер, серверы зон самостоятельно на корневые серверы запросов не отправляют. Если число машин за пределами данного домена, с которыми общаются пользователи данного домена, не очень велико, и все они компактно расположены в других доменах, то центральный сервер домена быстро заполнит свой кэш необходимой для разрешения запросов информацией. При этом такой кэш будет только один, а работать он будет с той же скоростью, как если бы каждый из серверов зон создавал его у себя.
С точки зрения самого домена в любом случае сервер зоны обращается к серверу домена за адресами из другой зоны, если только сервер другой зоны не указан в файлах базы данных named.
Приведем теперь пример файла named.boot, в котором проиллюстрируем использование указанных выше команд.
Пример 3. Содержание файла 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
Обычно, файл named.boot размещается в директории /etc. От этой директории затем идет отсчет места компонентов базы данных named. В нашем случае эту базу данных можно представить в виде графа (рисунок 3.10), у которого в качестве корня выступает директория /etc. В /etc существует поддиректория namedb, в которой располагаются все остальные файлы.
Рис.3.10. Структура размещения файлов базы данных named из примера 3
Сопоставив рисунок 3.10 и описание из примера 3, легко догадаться, что последняя колонка в каждой из команд описания настроек named заканчивается именем соответствующего файла или директории. Рассмотрим формат каждой команды более подробно.
Команда directory определяет директорию namedb как директорию размещения файлов базы данных named. Вообще говоря, вовсе не так уж обязательно размещать все файлы в одной директории. Можно создать несколько директорий, например, по количеству зон. Christophe Wolfhugel, например, для каждой зоны использует отдельную поддиректорию в корневой директории named. Если придерживаться этой логики размещения файлов, то получим следующее.
Пример 4. Содержание файла named.boot при размещении файлов описания зон для primary и secondary серверов по разным директориям
;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
В примере 4 в директории namedb определены две поддиректории v и p. В директории v размещаются файлы зон vega.ru и 43.226.194.in-addr.arpa, для которых данный сервер является primary. В свою очередь в директории p размещаются файлы описания зон polyn.kiae.su и 160.206.144.in-addr.arpa, для которых данный сервер является secondary сервером. Если представить структуру файлов в виде графа, то получится граф типа графа на рисунке 3.11.
Рис. 3.11. Дерево файлов описания базы данных named из примера 4
Вообще говоря, корнем описания файлов базы данных 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 <имя зоны> <имя файла описания зоны>
В примерах 3 и 4 используется три команды 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-адресов серверов зоны> <имя файла описания зоны>
В наших примерах описано две зоны, для которых данный сервер является secondary сервером - polyn.kiae.su и 160.206.144.in-addr.arpa. В примерах для каждой из этих зон указано по два IP-адреса серверов, которые описывают зону. Вообще говоря, достаточно указывать адрес только primary сервера для зоны. С точки зрения актуальности состояния базы данных зоны, для которой создается secondary сервер, указание одного только primary наиболее правильное решение, т.к. только primary сервер содержит наиболее актуальную базу данных зоны. Однако, в ряде случаев, имеет смысл указать несколько серверов, primary и secondary, например, в случае указания нескольких серверов, база копируется с того, который указан первым, если он доступен. Если сервер не доступен, то опрашивается следующий в списке, до первого доступного сервера.
Файл, который указан последним аргументом в команде secondary, создается named при запуске и постоянно обновляется в соответствии с описанием взаимодействия primary и secondary серверов. Редактировать вручную этот файл не имеет смысла, т.к. это калька с primary сервера, и через постоянные промежутки времени этот файл обновляется программой named. Таким образом, если кто-либо и внесет в него изменения, то named, создавая новую копию базы данных зоны, затрет эти изменения.
В отличии от primary, secondary сервер не способен поддерживать разрешение запросов сколь угодно долго. Как только истечет время актуальности данных в его базе данных, он пытается создать новую копию базы с базы данных primary сервера. Если это не удается, то сервер перестает обслуживать зону.
Главное назначение secondary сервера - это повышение надежности службы доменных имен. Описание зоны named копирует с серверов, указанных в качестве аргумента команды secondary. Там указаны не только primary сервер, но и другие secondary серверы. Зона копируется с того сервера, который доступен. Это значит, что на данном сервере может оказаться копия с другого secondary сервера, что, вообще говоря, не очень хорошо, если речь идет о сервере, который действительно предназначается для дублирования зоны.
В самом начале описания BIND было сказано, что сервис работает по 53 портам UDP и TCP. Для чего для одного и того же сервиса было организовывать информационные магистрали с использованием различных типов транспорта? Дело в том, что обычные запросы на разрешение имен IP-адресами или IP-адресов именами отправляются по транспорту UDP. Это делается из-за того, что объем передаваемой информации небольшой. Но при организации secondary сервера ситуация меняется. Этот сервер запрашивает другой сервер, прописанный в команде secondary, целиком все описание зоны, а это может быть довольно большой объем информации. Вот в этом случае и используется сервис TCP. Из-за такой архитектуры проистекают многие проблемы связанные как со скоростью обслуживания запросов к системе доменных имен, так и с безопасностью сети вообще.
Скорость DNS - "это притча во языцах". При установке больших временных интервалов ожидания ответов отказ на обслуживание приходит только после истечения времени ожидания для данного сервиса UDP. Это если сервис неактивен. Если сервис активен, то нельзя точно установить работает он или нет, т.к. сервис UDP - это сервис без установки соединения. Но если говорить о копировании зон, то можно столкнуться со следующей ситуацией: запросы разрешаются, а зоны не копируются. В этом случае кроме администратора данного сервера никто ничего сказать не может. Администратор может намерено запретить копирование зоны, а может быть за отведенный интервал времени не удается передать зону, или во время передачи разрывается TCP сессия. Для российской части Internet такое случается довольно часто. Если вдруг пользователям кажется, что система начинает медленно "умирать", то это может происходить из-за того, что secondary сервера не могут обновить описания зон, а так как копии могут быть получены в разное время, то сервера "мрут" в разное время.
Команда 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.
Пример 5. Файл cache (Февраль 1996 года)
; Servers from the root domain ; ftp://nic.ddn.mil/netinfo/root-servers.txt . 99999999 IN NS A.ROOT-SERVERS.NET . 99999999 IN NS B.ROOT-SERVERS.NET . 99999999 IN NS C.ROOT-SERVERS.NET . 99999999 IN NS D.ROOT-SERVERS.NET . 99999999 IN NS E.ROOT-SERVERS.NET . 99999999 IN NS F.ROOT-SERVERS.NET . 99999999 IN NS G.ROOT-SERVERS.NET . 99999999 IN NS H.ROOT-SERVERS.NET . 99999999 IN NS I.ROOT-SERVERS.NET ; Root servers by address A.ROOT-SERVERS.NET 99999999 IN A 198.41.0.4 B.ROOT-SERVERS.NET 99999999 IN A 128.9.0.107 C.ROOT-SERVERS.NET 99999999 IN A 192.33.4.12 D.ROOT-SERVERS.NET 99999999 IN A 128.8.10.90 E.ROOT-SERVERS.NET 99999999 IN A 192.203.230.10 F.ROOT-SERVERS.NET 99999999 IN A 192.5.5.241 G.ROOT-SERVERS.NET 99999999 IN A 192.112.36.4 H.ROOT-SERVERS.NET 99999999 IN A 128.63.2.53 I.ROOT-SERVERS.NET 99999999 IN A 192.36.148.17
Формат записей этого файла мы обсудим позже при рассмотрении форматов записей файлов базы данных описания зоны.
Все что было сказано о содержании файла из команды cache относится к случаю, когда в качестве имени зоны указана ".". Это означает, что описывается корневая зона, что в свою очередь означает описание корневых серверов доменных имен, к которым named обращается при работе в режиме нерекурсивной процедуры разрешения запросов на IP-адрес по имени или запросов на имя по IP-адресу.
Если в файл chache необходимо внести другую информацию, то это делается аналогично описанию корневых серверов. Реализация файла cache, отличного от указанного в примере 5 будет рассмотрена для случая делегирования зоны в домене.
Команда 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 будет выглядеть так, как показано в примере 6.
Пример 6. Подчиненный сервер, работающий по рекурсивной процедуре разрешения запросов от resolver
;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
Фактически, команда slave позволяет организовать, в некотором смысле, "интеллектуальный" resolver.
Перейдем теперь к описанию содержания файлов базы данных named. Все эти файлы состоят из записей, которые имеют одинаковый формат и называются записями описания ресурсов.
Формат записи определяется документом RFC-1033, и имеет следующий вид:
<name> <ttl> <class> <type> <data>
Все поля отделяются друг от друга пробелом или табуляцией. Каждое из них имеет следующее значение:
Поле name - это имя объекта. Объектом может быть хост, домен и поддомен. Существуют специальные правила именования объектов, которые базируются на понятии текущего имени домена. Программа named анализирует файл базы данных начиная с первой записи последовательно до последней записи файла. Первоначально текущим именем домена является имя, указанное в командах primary, secondary или cache файла named.boot, в зависимости от того о каком файле базы данных named идет речь, если первая запись этого файла содержит имя @. В противном случае для определения текущего имени должна быть указана команда $ORIGIN. Если имя в записи описания ресурса опущено, то ресурс относится к текущему имени домена. Если имя указано без точки на конце, то оно расширяется текущим именем домена. Для изменения текущего имени домена следует ввести либо команду $ORI-GIN, либо указать имя записи ресурса с точкой на конце. Если в качестве имени указана одна точка (".") или две точки ("..") то такая запись описывает домен root, т.е. корневой домен. Если в имени записи встречается символ "*", то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. В англоязычных источниках это называют "wildcard character". Для пользователей любой операционной системы употребление этого символа хорошо знакомо по командам dir (MS-DOS) или ls (Unix). Например, при необходимости получить список файлов, оканчивающихся расширением "bak", выдается команда:
/usr/paul>ls *.bak
Точно также используется этот символ и в имени записи базы данных описания домена. Если в поле имени указан только символ "*", то это предполагает "*.<имя текущего домена>". Если за "*" следует имя, то оно ограничивает расширение имен "*". Например, "*.polyn.kiae.su." определяет все имена из домена polyn.kiae.su, в том числе и имена машин в поддоменах, а не только имена машин в домене и имена самих поддоменов. Наиболее часто "*" используется в записях MX, которые регулируют обмен электронной почтой.
Поле ttl - это поле определяет время (в секундах), в течении которого данная запись сохраняется в кэше. Значение поля задается в виде восьми десятичных цифр, таким образом, максимальное значение ttl - 99999999. Именно это значение и задается для корневых серверов доменных имен в примере 5. Если это поле оставлено пустым, то по умолчанию принимается значение, указанное в параметре minimum поля данных (data) записи SOA для данной зоны.
Поле class определяет класс записи описания ресурса. В Internet используется только один класс записей - класс IN. В принципе существуют еще классы HS (Hessiod) и CH (Chaos), но в рамках нашего предмета - системы доменных имен Internet, они не рассматриваются. Некоторые авторы, например, Ronny H.Kavli, который написал комментарии к FAQ Kaig Richmond, считает, что наличие этого поля только "замутняют чистый лик" базы данных описания ресурсов DNS. В любом случае все записи из базы данных named имеют вид:
<name> <ttl> IN <type> <data>
Поле type определяет тип записи описания ресурсов. К таким типам относятся: SOA (Start Of Authority), NS (Name Server), A (Address), MX (Mail eXchanger) CNAME (Canonical NAME), WKS (Well Known Services), PTR (PoinTeR), HINFO (Host INFOrmation). Перечисленные выше типы записей составляют набор стандартных записей, которые могут встретиться в базе данных описания домена. Кроме этих типов существуют еще и экспериментальные типы. Все они касаются, главным образом, возможностей управления почтой. Следует заметить, что не все стандартные записи используются в базах данных описания доменов. Так российские администраторы редко пользуются записями типа HINFO и WKS. Некоторые администраторы считают, что вместо CNAME лучше назначить еще один адрес через запись типа A, существуют и другие предпочтения.
В поле data указываются данные для каждой записи описания ресурсов. Для различных типов записей формат данных также различный и соответствует назначению записи описания ресурсов.
Кроме записей описания ресурсов в файлах описания базы данных домена могут встречаться и другие записи. Самые распространенные из них - это записи комментариев. Запись комментария начинается с символа ";" в первой позиции строки. Все что следует до конца строки рассматривается в этом случае как комментарий. Если этот символ встретится в середине строки, то программа предполагает, что все, что следует далее до конца строки - это комментарий. При разборе записей описания ресурсов я постараюсь обратить внимание на использование комментариев.
Если данные не помещаются в пределы экрана, то можно использовать продолжение описания записи на другую строку. Я не пишу здесь "если данные не помещаются на одной строке", т.к. это будет не верно с точки зрения представления файла базы данных в файловой системе. В принципе длина строки может иметь достаточно большую длину, достаточную для того, чтобы вместить описание записи ресурсов, но это неудобно для редактирования файла базы данных, т.к. длина отображаемой строки на экране большинства алфавитно-цифровых дисплеев ограничена 80-ю символами. В описании файла базы данных домена не предусмотрен символ продолжения записи типа "\" в csh Unix. В качестве механизма продолжения записей используется пара скобок "(", ")". Если в некоторой строке встретилась открывающая скобка "(", то все данные до закрывающей скобки будут приписаны к этой строке.
Другим механизмом, который используется при описании элементов записи описания ресурса является маскирование символов. Маскирование символов применяется в том, случае, если необходимо использовать символ, который имеет особое значение для записей описания ресурсов. Например, символ "@". Для этого используется символ обратного слэша "\". Аналогично языку программирования С символ можно указывать и цифрами. Только в этом случае используется десятичное число, которое соответствует коду ASCII, например, "\040" также обозначает символ "@".
Назад | Содержание | Вперед
[an error occurred while processing this directive]