{name};  {ttl}   addr-class   Record-Type   Record-Specific-data

Записи ресурсов имеют стандартный формат, показанный выше. Первым полем всегда является имя доменной записи и оно всегда должно начинаться в первой колонке. Для всех RR не являющихся от первого в файле, имя может быть оставлено пустым; в этом случае она возьмет имя предыдущей RR. Второе поле - это опциональное поле времени жизни (ttl). Оно описывает сколько времени эти данные будут храниться в базе данных. Если это поле оставлено пустым, то время жизни по умолчанию определяется в записи ресурса Начала Полномочий (Start Of Authority)(смотри ниже). Третье поле - это класс адреса; В настоящее время поддерживается только один класс: IN для адресов internet и и другой информации. Включена дополнительная поддержка для класса HS, необходимого для информации MIT/Athena "Hesiod". Четвертое поле устанавливает тип записи ресурса. Последующие поля зависят от типа записи ресурса. Регистр букв сохраняется во время загрузки данных в сервер имен. Все сравнения и поиски в базе данных сервера имен не зависят от регистра.

Следующие символы имеют специальные значения:

 
	"."

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

 
	"@"

Отдельно стоящее @ в поле имени обозначает текущий источник.

 
	"\X"

Где X - любой символ кроме цифр (0-9), квотирует этот символ, та что его специальное значение не применяется. Например, "\." может быть использовано, чтобы поместить знак точки в метку.

 
	"\DDD"

Где каждая D - цифра, означает октет соответствующий десятичному числу, описанному DDD. Полученный октет считается текстом и не проверяется на специальное значение.

 
	"( )"

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

 
	";"

Точка с запятой начинает комментарий; оставшаяся часть строки игнорируется. Заметьте, что полностью пустая строчка также считается комментарием и игнорируется.

 
	"*"

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

Везде где встречается имя - в поле имени или в каких-либо полях содержащих имена - если имя не заканчивается на ".", то будет добавлен текущий источник (@). Это полезно для добавления текущего имени домена к данным, таким как имена машин, но может создать проблемы, если вы не хотите, чтобы это происходило. Хороший практический метод: если имя не находится в домене, для которого вы создаете файл данных, заканчивайте такое имя ".".

6.5.1. $INCLUDE

Строчка включений начинается с $INCLUDE, начиная с первой колонки, и продолжается именем файла, и, необязательно, новым временным $ORIGIN используемым пока этот файл считывается. Эта особенность, в частности, полезна для разделения различных типов данных на несколько файлов. Например:

  
	$INCLUDE /usr/local/adm/named/data/mail-exchanges

Эта строчка может быть интерпретирована как запрос на считывание файла /usr/local/adm/named/data/mail-exchanges. Комманда $INCLUDE не заставляет считывать данные в различные зоны или деревья. Она предоставляет простую возможность организовать данные данного первичного домена в отдельных файлах. Одна лишь особенность "временного $ORIGIN" описанная выше не достаточна для того чтобы разделить ваши данные на некоторые другие зоны - границы зон могут быть введены только в файле начальной загрузки.

Файл $INCLUDE в своей первой записи ресурса должен иметь имя. Это означает, что первый символ первой не закомментированной строки не должен быть пробелом. Текущее имя по умолчанию в родительском файле не приводит к файлу $INCLUDE.

6.5.2. $ORIGIN

Источник (origin) - способ изменения источника в файле данных. Строка начинается с первой колонки и продолжается доменным источником. Кажется, что это может быть полезно для содержания более чем одной зоны в файле данных, но это работает совсем не так. Сервер имен по существу дела требует, чтобы данная зона полностью отображалась в некотором определенном файле. Таким образом, вы должны быть очень осторожны и использовать $ORIGIN только один раз в начале файла или внутри файла для перехода к "более низкому" домену в зоне - но никогда к совершенно иной зоне.

6.5.3. SOA - Начало Полномочий

	{name}  {ttl}  addr-class   SOA     Origin               Person in charge
	@              IN           SOA     ucbvax.Berkeley.Edu.
	kjd.ucbvax.Berkeley.Edu. (
	                                    1995122103   ; Serial
	                                    10800        ; Refresh
	                                    1800         ; Retry
	                                    3600000      ; Expire
	                                    259200 )     ; Minimum

Начало Полномочий. Запись SOA, обозначает начало зоны. Имя - это имя зоны и часто задается как "@", так как это всегда текущий $ORIGIN и запись ресурса SOA обычно первая запись в файле первичной зоны. Origin - это имя хоста на котором находится этот файл данных (говоря иначе, первичный главный (primary master)сервер для этой зоны). Ответственное лицо (Person in charge) - это адрес электронной почты человека ответственного за сервер имен, с "@" замененной на ".". Серийный номер (serial number) - это номер версии этого файла данных, который должен быть положительным целым числом. Этот номер должен увеличиваться каждый раз, когда в данные вносятся изменения. Старые сервера разрешали использовать фантомную "." в этом и других числах в файле данных; n.m считалось как "n000m", а не как более интуитивное "n*1000+m" (так что 1.234 переводилось в 1000234 а не в 1234). Эта особенность сильно осуждалась из-за ее непонятности, непредсказуемости, и вообще она была абсолютно ненужной. Нужно отметить, что используя запись "YYYYMMDDNN" вы можете делать до 100 изменений в день вплоть до 4294 года. А вообще вы можете использовать такой тип записи, который для вас более удобен. Если вы хорошо программируете на perl вы даже можете использовать номера версий RCS для генерации серийного номера. Поле Refresh показывает как часто (в секундах)вторичные сервера имен должны проверять первичный сервер имен, чтобы узнать, не нужно ли обновить зону? Поле Retry показывает как долго (в секундах) вторичный сервер должен ждать перед тем как повторить проваленную передачу зоны. Поле Expire указывает верхнее ограничение, в секундах, в течение которого вторичный сервер может использовать данные до того как они потеряют силу из-за отсутствия обновления. Поле Minimum - это количество секунд, используемое по умолчанию для времени жизни (ttl) в записях ресурсов. Оно также является вынужденным минимумом для Времени Жизни, если оно определено в какой-либо записи ресурса (RR) в зоне. Для каждой зоны должна быть только одна запись SOA.

6.5.4. NS - Сервер Имен

 
	{name}   {ttl}   addr-class   NS   Name-servers-name

	                 IN           NS   ucbarpa.Berkeley.Edu.

Запись Сервер Имен, NS, описывает сервер имен ответственный за данный домен, создавая точку делегирования и подзону. Первое поле имени описывает зону обслуживаемую сервером имен во втором имени. Для каждой зоны необходимо по крайней мере два сервера имен.

6.5.5. A - Адрес

 
	{name}   {ttl}   addr-class   A    address

	ucbarpa          IN           A    128.32.0.4
	                 IN           A    10.0.0.78

Запись Адрес, A, описывает адрес указанной машины. Поле имени описывает имя машины, а поле адреса - сетевой адрес.Для каждого адреса машины должна быть одна запись A.

6.5.6. HINFO - Информация о Хосте

	{name}   {ttl}    addr-class  HINFO   Hardware    OS

	                  IN          HINFO   VAX-11/780  UNIX

Запись Информация о Хосте, HINFO, предназначена для специфических данных о хосте. Она предназначена для описания This lists the аппаратуры и операционной системы, работающей на описанном хосте. Если вы хотите включить пробел в имя машины, то бы должны заключить имя в кавычки (используя символы ""). На каждый хост может существовать одна запись HINFO, хотя из-за соображений безопасности большинство доменов вообще не содержат ни одной записи HINFO. Ни одна программа от нее не зависит.

6.5.7. WKS - Известные Сервисы (Well Known Services)

   {name}   {ttl}    addr-class  WKS   address     protocol   list-of-services
                     IN          WKS   128.32.0.10 UDP        who route timed domain
                     IN          WKS  128.32.0.10 TCP       ( echo telnet discard
   sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth
   time whois mtp pop rje finger smtp supdup hostnames domain nameserver )

Запись Известные Сервисы, WKS, описывает известные сервисы, поддерживаемые определенным протоколом по указанному адресу. Список сервисов и номеров портов берется из списка сервисов описанных в /etc/services. На каждый протокол на каждый адрес должна быть только одна запись WKS. Вот что говорит RFC1123 о записях WKS:

2.2 Использование Сервиса Доменных Имен

...

Приложение НЕ ДОЛЖНО надеяться на возможность обнаружить запись WKS содержащую точное перечисление всех сервисов по конкретному адресу хоста, так как запись ресурса WKS не слишком часто используется в Internet. Чтобы удостовериться, что сервис присутствует, просто попытайтесь его использовать.

...

5.2.12 Использование WKS при обработке MX: RFC-974, стр. 5

RFC-974 [SMTP:3] рекомендуется опрашивать доменную систему по поводу записи WKS ("Известные Сервисы"), чтобы удостовериться, что каждая предполагаемая почтовая цель поддерживает SMTP. Опыт показывает, что WKS не имеет широкой поддержки, поэтому шаг поиска WKS при обработке MX НЕ НУЖНО использовать.

...

6.1.3.6 Status of RR Types

...

Типы записей ресурсов TXT и WKS не имеют широкого использования в Internet; в результате, приложения не могут положиться на существование записей ресурсов типа TXT или WKS в большинстве доменов.

6.5.8. CNAME - Каноническое имя

	alias     {ttl}     addr-class   CNAME   Canonical-name
 
	ucbmonet            IN           CNAME   monet

Запись ресурса Каноническое Имя (Canonical Name), CNAME, указывает псевдоимя или псевдоним для официального, или канонического, имени хоста. Только одна эта запись должна ассоциироваться с псевдонимом. Все остальные записи должны ассоциироваться с каноническим именем, а не псевдоименем. Любая запись ресурса, включающая доменное имя как свое значение (например, NS или MX) должна содержать каноническое имя, а не псевдоимя. Аналогично, при поиске записей ресурсов типа A будут следовать CNAME, а при других записях, типа MX или NS и большинстве других - нет. Канонические имена (CNAME) могут указывать на другие CNAME, но это выглядит очень небрежно.

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

6.5.9. PTR - Указатель на Доменное Имя

	name      {ttl}     addr-class   PTR     real-name

	7.0                 IN           PTR     monet.Berkeley. Edu.

Запись Указатель на Доменное Имя (Domain Name Pointer), PTR, позволяет специальным именам указывать в какое-либо иное местонахождение в домене. Предыдущий пример записи PTR используется при установке обратного указателя для специального домена IN-ADDR.ARPA. Эта строка взята из примера файла hosts.rev. Записи PTR необходимы для функции gethostbyaddr. Нужно отметить последнюю "." которая защищает от добавления BIND текущего $ORIGIN к этому доменному имени.

6.5.10. MX - Почтовый Коммутатор (Mail Exchange)

	name      {ttl}     addr-class   MX      preference value    mail exchange 

	Munnari.OZ.AU.      IN           MX      0                  Seismo.CSS.GOV.
	*.IL.               IN           MX      0                  RELAY.CS.NET.

Записи Mail eXchange, MX, используются для обозначения списка хостов, которые сконфигурированы для приема почты посланной на это доменное имя. Каждое имя, получающее почту должно иметь MX, потому что если кто-то не найден во время доставки почты, MX будет "введен" со стоимостью 0 и сам будет являться адресатом информации для хоста. Если вы хотите, чтобы хост сам получал свою почту, вы должны создать запись MX для имени вашего хоста, указывающую на имя хоста. Лучше, чтобы это было явно указано, чем позволить ввести это удаленным почтовым отправителям. В первом примере выше, Seismo.CSS.GOV. - это почтовый шлюз, знающий как доставить почту в Munnari.OZ.AU.. Эти две машины могут иметь свои собственные подключения или использовать различные способы передачи данных. "preference value" - это указание отправителю повторять передачу, если имеется более одного пути для доставки почты на определенную машину. Заметьте, что более низкие числа показывают более высокий приоритет, а отправители должны использовать в произвольном порядке хосты MX с одинаковым приоритетом для равномерного распределения нагрузки если стоимость одинакова. Для более подробной информации смотри RFC974.

Имена заданные с использованием символа "*" (вместо любых символов) могут быть использованы для почтовой маршрутизации с записями MX. Вероятно, в сети имеются сервера, которые просто считают, что любая почта для домена должна быть маршрутизирована через транслятор (relay). Второй пример выше: вся почта для хостов в домене IL маршрутизируется через RELAY.CS.NET. Это задано с помощью создания записи ресурса с использованием "wildcard", который указывает, что *.IL имеют MX на RELAY.CS.NET. Записи MX с "wildcard" на практике не очень-то и полезны, ведь даже если почтовое сообщение поступает на шлюз для заданного домена, оно все еще должно быть маршрутизировано внутри этого домена, и в настоящее время невозможно иметь явно разный набор записей MX внутри и снаружи домена. Если вам не понадобятся какие-либо Почтовые Коммутаторывнутри вашего домена, ну что же, тогда вперед, смело используйте "wildcard". Если вы хотите использовать записи MX с использованием "wildcard" как для записей "верхнего уровня" так и для специфических "внутренних" записей, то заметьте, что каждая специфическая запись должна будет "заканчиваться" полным перечислением данных, содержащихся в записи для "верхнего уровня". Это необходимо из-за того, что специфические записи MX возьмут верх над записями "верхнего уровня" с использованием "wildcard", и будут выполнять функции "верхнего уровня", если данный внутренний домен может принимать почту снаружи через шлюз. Записи MX с "wildcard" - очень тонкое дело, поэтому вы должны быть очень осторожны с ними.

6.5.11. TXT - Текст

	name   {ttl}   addr-class   TXT   string
	Munnari.OZ.AU. IN           TXT   "foo"

Запись TXT содержит текстовые данные любого вида. Синтаксис текста зависит от домена, где он был найден; многие системы используют записи TXT для кодирования локальных данных в стилизованном формате. MIT Hesiod - одна из таких систем.

6.5.12. RP - Ответственная Персона

   owner   {ttl}  addr-class   RP    mbox-domain-name   TXT-domain-name
   franklin       IN           RP    ben.franklin.berkeley.edu. sysadmins.berkeley.edu.

Запись "Ответственная Персона", RP, определяет имя или группу имен ответственных за хост. Обычно желательно, чтобы было возможно определить существо, ответственное за определенный хост. Когда этот хост находится в выключенном состоянии или работает неправильно, вы можете захотеть познакомиться слюдьми, кто может быть ответственнен за восстановление хоста.

Первое поле, mbox-domain-name - это доменное имя, определяющее почтовый ящик ответственного человека. Его формат в файле зон использует соглашение DNS по кодированию почтовых ящиков, идентичное тому, что использовалось в записи SOA в поле почтового ящика для Ответственной Персоны (Person-in-charge). В вышеприведенном примере, mbox-domain-name показывает зашифрованное "<ben@franklin.berkeley.edu>". Может быть определен корневой домен (просто "."), что будет указывать на то, что почтового ящика нет.

Второе поле, TXT-domain-name - это имя домена для которого существует запись TXT. Может быть осуществлен последующий запрос для получения соответствующей записи ресурса TXT для TXT-domain-name. Это обеспечивает уровень косвенной адресации, так что на человека можно делать ссылки из различных мест в DNS. Для TXT-domain-name может быть определен корневой домен (просто ".") что будет показывать, что не существует соответствующих Записей Ресурса типа TXT. В вышеприведенном примере "sysadmins.berkeley.edu." - это имя записи TXT, которая может содержать некоторый текст с именамии телефонными номерами.

Формат записи RP не чувствителен к классу. На одно имя в базе данных может быть множество записей RP, но они должны имет одинаковое TTL.

Запись RP все еще экспериментальна; не все сервера имен поддерживают или распознают ее.

6.5.13. AFSDB - Сервер DCE или AFS

	name     {ttl}    addr-class  AFSDB   subtype   server-host-name
	toaster.com.      IN          AFSDB   1         jack.toaster.com.
	toaster.com.      IN          AFSDB   1         jill.toaster.com.
	toaster.com.      IN          AFSDB   2         tracker.toaster.com.

Запись AFSDB используется для обозначения хостов, обеспечивающих некоторый тип распределенного сервиса, рекламируемого в этом доменном имени. Значение subtype (аналогично значению "preference" в записи MX) показывает, какой тип распределенного сервиса обеспечивает данное имя. Subtype 1 показывает, что названный хост является сервером баз данных AFS (R) для элемента AFS в данном доменном имени. Subtype 2 показывает, что названный хост обеспечивает сервис имен внутри элемента для элемента DCE (R) названного данным доменным именем. В вышеприведенном примере, jack.toaster.com и jill.toaster.com объявляются как сервера баз данных для элемента AFS toaster.com, так что клиенты AFS которым нужен сервис от toaster.com направляются на эти два хоста за дальнейшей информацией. Третья запись объявляет что tracker.toaster.com содержит сервер директорий для корня ячейки DCE toaster.com, так что клиенты DCE, желающие обратиться к сервису DCE должны проконсультироваться с хостом tracker.toaster.com по поводу дальнейшей информации. Подтип записи DCE обычно сопровождается записью TXT описывающей все остальные детали, используемые при доступе к элементу DCE. RFC1183 содержит более подробную информацию об этом типе записи.

Запись AFSDB все еще экспериментальна; не все сервера имен поддерживают или распознают ее.

6.5.14. PX - Указатель преобразование информации X.400/RFC822

   name    {ttl}   addr-class   PX   prefer    822-dom    X.400-dom

   *.ADMD-garr.X42D.it.   IN    PX   50        it.        ADMD-garr.C-it.
   *.infn.it.             IN    PX   50        infn.it.   O.PRMD-infn.ADMD-garr.C-it.
   *.it.                  IN    PX   50        it.        O-gate.PRMD-garr.ADMD-garr.C-it.

Записи PX (Указатель на преобразование информации X.400/RFC822) используются для указания правил преобразования адресов между адресами X.400 O/R и почтовыми адресами типа RFC822 (доменного типа). Для более детального описания процесса преобразования смотри RFC1327.

Имеется 3 различных типа правил преобразования:

1. преобразование из X.400 в RFC822 (определяется как "table 1 rules" в RFC1327)
2. преобразование из RFC822 в X.400 (определяется как "table 2 rules" в RFC1327)
3. кодирование RFC822 в X.400 (определяется как "gate table" в RFC1327)

Все три типа правил преобразованич определены использованием Записи Ресурса типа PX в DNS, несмотря на то, что значение name различны: для случая 1, значение name - это домен X.400 в синтаксисе DNS, тогда как для случаев 2 и 3 значение name является доменом RFC822. Чтобы узнать, как описать домен X.400 в синтаксисе DNS и использовать в нем ключевое слово X42D, смотри RFC-1664. Имеется определенный инструментарий для преобразования таблиц из формата RFC1327 в формат файлов в синтаксисе DNS. Preference аналогично параметру Preference в Записи Ресурса MX: в настоящее время для него советуется использовать фиксированное значение 50. 822-dom задает правило преобразования для части RFC822, а X.400-dom задает правило преобразования для части X.400 (в синтаксисе DNS). В настоящее время советуется всегда использовать значения name с символом любого знака (wildcarded),так как спецификации таблиц RFC1327 позволяют только "wildcard" спецификации. Это нужно для того, чтобы сохранить совместимость с существующими сервисами, использующими статические таблицы RFC1327 вместо информации DNS PX.

Спецификации правил преобразования из X.400 в синтаксис RFC822 требуют создания соответствующего доменного дерева X.400 в DNS, включая также специфические записи SOA и NS для самого домена. Спецификации правил преобразования из RFC822 в X.400 могут быть встроены прямо в нормальное прямое дерево name. И опять скажем: для более детального описания организации подобных структур смотрите RFC1664.

Инструментальные программы и библиотеки, основанные на стандартных программах и библиотеках разрешителя, могут получить из DNS правила преобразования в синтаксисе RFC1327 или DNS.

И снова, смотрите RFC1664, о том как использовать Запись Ресурса PX, и будьте осторожны в координировании информации о преобразовании, которую вы можете определить в DNS с подпбной информацией определенной в статичных таблицах RFC1327.

Запись PX все еще экспериментальна; не все сервера поддерживают или распознают ее.

6.6. Обсуждение

Использование различных полей Времени Жизни (Time To Live) в RRset было осуждено и теперь устанавливается сервером во время загрузки первичной зоны. Смотри раздел "Безопасность", где обсуждаются разные TTL.

Назначение Времени Жизни для записей и для зоны посредством поля Minimum в записи SOA очень важно. Высокие значения приведут к низкому сетевому траффику BIND и более быстрому времени ответа. Более низкие значения приведут к генерации большого количества запросов но обеспечат быстрое распространение изменений.

TTL влияет только на изменения и удаления из зоны. Добавления распространяются в соответствии со значение Refresh в SOA.

Опыт показывает, что значение TTL по умолчанию для зон меняется от 0.5 дня до 7 дней. Вы можете попробовать увеличить TTL по умолчанию, которое показывается в прошлых версиях этого руководства от одного дня (86400 секунд) до трех дней (259200 секунд).

Это очень сильно уменьшит количество запросов к вашим серверам имен.

Если вам нужно быстрое распространение изменений и удалений, мудрым решением может стать уменьшение значения поля Minimum за несколько дней до изменений, затем сделать нужные изменения и восстановить TTL в его прежнем значении.

Если ваши зоны достаточно стабильны (вы в основном добавляете новые записи без изменений и удалений старых) то вы даже можете попробовать установить значение TTL больше чем три дня.

Заметьте, что в любом случае, не имеет смысла иметь записи с TTL ниже чем значение задержки SOA Refresh, так как Задержка - это время требуемое для вторичных серверов для получения копии заново модифицированной зоны.

6.7. О "безопасных зонах"

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

Для того, чтобы использовать безопасность зоны, named должен быть скомпиллирован с выставленным SECURE_ZONES и вы должны иметь по крайней мере одну Запись Ресурса secure_zone TXT. Пока для данной зоны не существует запись secure_zone, не может быть предпринято никаких ограничений к данным в этой зоне. Формат Записи Ресурса secure_zone TXT следующий:

	secure_zone     addr-class     TXT     string

Здесь addr-class может быть или HS или IN. Синтаксис для строчки TXT или "network address:netmask" или "host IP address:H".

"network address:netmask" позволяет делать запросы из всей сети. Если сетевая маска опущена, для указанного сетевого адреса named будет использовать сетевую маску по умолчанию.

"host IP address:H" позволяет делать запросы с хоста. "H" после ":" требуется для отделения адреса хоста от адреса сети. В одном файле зоны может существовать множество Записей Ресурсов secure_zone TXT.

Например, вы можете установить так, что зона будет отвечать только на запросы Hesiod из сети класса B 130.215.0.0 и с хоста 128.23.10.56, если вы добавите следующие две записи ресурса типа TXT:

	secure_zone     HS     TXT     "130.215.0.0:255.255.0.0" 
	secure_zone     HS     TXT     "128.23.10.56:H" 

Эта особенность может быть использована для ограничения доступа к карте паролей Hesiod или для раздельного разрешения внутренних и внешних адресов internet на фаервольной (firewall) машине без необходимости запуска отдельного named для внутреннего и внешнего разрешения адресов.

Заметьте, что вам нужно будет включить ваш кольцевой (loopback) интерфейс (127.0.0.1) в вашу запись secure_zone, или ваши локальные клиенты не смогут разрешить имена.

6.8. О Hesiod, и Записи Ресурса HS-class

Hesiod, разработанный MIT Project Athena - это информационный сервис, построенный на BIND. Его цель аналогична Sun'овскому NIS: для доставки информации о пользователях, группах, доступных по сети файловых системах, принтерах, и почтовых сервисах по всем инсталляциям. Кроме того, что эта штука использует BIND вместо отдельного серверного кода, еще одним важным различием между Hesiod и NIS является то, что Hesiod не собирается иметь дело с паролями и идентификацией, а только с данными, не требующими повышенной безопасности. Сервера Hesiod могут быть организованы добавлением записей ресурсов в сервера BIND; или как отдельные сервера с отдельным администрированием.

Чтобы побольше узнать и раздобыть Hesiod зайдите по anonymous FTP на хост ATHENA-DIST.MIT.EDU и вытащите компрессированный tar файл /pub/ATHENA/hesiod.tar.Z. Вам не понадобятся новые библиотеки named и разрешителя так как их функциональные возможности уже были интегрированы в BIND начиная с версии 4.9. Чтобы узнать как Hesiod функционирует в виде части вычислительной среды Athena вытащите документ /pub/ATHENA/usenix/athena-changes.PS с того же FTP сервера. Там еще есть tar файл с примерами файлов ресурсов Hesiod.

в то время как использование класса Hesiod все еще открытый вопрос, те же самые сервисы возможно могут быть обеспечены использованием записей класса IN, типа TXT и типа CNAME. В любом случае, код и документация для Hesiod помогут узнать как установить и использовать этот сервис.

Заметьте, что в то время как BIND включает поддержку для запросов класса HS, логика передачи зон для зон, отличных от класса INвсе еще находится на стадии эксперимента.

6.9. Примерные Файлы

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

6.9.1. Загрузочные Файлы

	; 
	; Boot file for Primary Name Server
	; 
	            ;type         domain                  source file or host
	;
	             directory    /usr/local/adm/named
	             primary      Berkeley.Edu            ucbhosts
	             primary      32.128.in-addr.arpa     ucbhosts.rev
	             primary      0.0.127.in-addr.arpa    named.local
	             cache;       .                       root.cache

6.9.1.2. Вторичный Сервер

	;
	; Boot file for Secondary Name Server
	;
	;type         domain                  source file or host
	;
	directory    /usr/local/adm/named
	secondary    Berkeley.Edu            128.32.0.4 128.32.0.10 ucbhosts.bak
	secondary    32.128.in-addr.arpa     128.32.0.4 128.32.0.10 ucbhosts.rev.bak
	primary      0.0.127.in-addr.arpa    named.local
	cache        .                       root.cache

	;
	; Boot file for Caching Only Name Server
	;
	;type         domain                  source file or host
	;
	directory     /usr/local/adm/named
	cache         .                       root.cache
	primary       0.0.127.in-addr.arpa    named.local

6.9.2.Удаленный Сервер / Клиент DNS

6.9.2.1. /etc/resolv.conf

	domain Berkeley.Edu
	nameserver 128.32.0.4
	nameserver 128.32.0.10
	sortlist   130.155.160.0/255.255.240.0 130.155.0.0

6.9.3. root.cache

	;
	;     This file holds the information on root name servers needed to
	;     initialize cache of Internet domain name servers
	;     (e.g. reference this file in the "cache  .  <file>"
	;     configuration file of BIND domain name servers).
	;
	;     This file is made available by InterNIC registration services
	;     under anonymous FTP as
	;            file          /domain/named.root
	;            on server     FTP.RS.INTERNIC.NET
	;   -OR- under Gopher at   RS.INTERNIC.NET
	;        under menu        InterNIC Registration Services (NSI)
	;        submenu           InterNIC Registration Archives
	;            file          named.root
	;
	;   last update:     Oct 5, 1994
	;   related version of root zone:   1994100500
	;
	.                 604800     IN    NS    NS.INTERNIC.NET.
	NS.INTERNIC.NET.  604800     IN    A     198.41.0.4
	.                 604800     IN    NS    NS1.ISI.EDU.
	NS1.ISI.EDU.      604800     IN    A     128.9.0.107
	.                 604800     IN    NS    C.PSI.NET.
	C.PSI.NET.        604800     IN    A     192.33.4.12
	.                 604800     IN    NS    TERP.UMD.EDU.
	TERP.UMD.EDU.     604800     IN    A     128.8.10.90
	.                 604800     IN    NS    NS.NASA.GOV.
	NS.NASA.GOV.      604800     IN    A     128.102.16.10
	                  604800     IN    A     192.52.195.10
	.                 604800     IN    NS    NS.ISC.ORG.
	NS.ISC.ORG.       604800     IN    A     192.5.5.241
	.                 604800     IN    NS    NS.NIC.DDN.MIL.
	NS.NIC.DDN.MIL.   604800     IN    A     192.112.36.4
	.                 604800     IN    NS    AOS.ARL.ARMY.MIL.
	AOS.ARL.ARMY.MIL. 604800     IN    A     128.63.4.82
	                  604800     IN    A     192.5.25.82
	.                 604800     IN    NS    NIC.NORDU.NET.
	NIC.NORDU.NET.    604800     IN    A     192.36.148.17
	; End of File

6.9.4. named.local

	@   IN   SOA   ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
	               1994072100           ; Serial
	               10800                ; Refresh
	               1800                 ; Retry
	               3600000              ; Expire
	               259200 )             ; Minimum
	    IN   NS    ucbvax.Berkeley.Edu. ; pedantic
	1   IN   PTR   localhost.

6.9.5. host.rev

	; 
	;  @(#)ucb-hosts.rev    1.1    (Berkeley)    86/02/05
	;
	@      IN   SOA   ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
	                  1986020501           ; Serial
	                  10800                ; Refresh
	                  1800                 ; Retry
	                  3600000              ; Expire
	                  259200 )             ; Minimum
	       IN   NS    ucbarpa.Berkeley.Edu.
	       IN   NS    ucbvax.Berkeley.Edu.
	0.0    IN   PTR   Berkeley-net.Berkeley.EDU.
	       IN   A     255.255.255.0
	0.130  IN   PTR   csdiv-net.Berkeley.EDU.
	4.0    IN   PTR   ucbarpa.Berkeley.Edu.
	6.0    IN   PTR   ernie.Berkeley.Edu.
	7.0    IN   PTR   monet.Berkeley.Edu.
	10.0   IN   PTR   ucbvax.Berkeley.Edu.
	6.130  IN   PTR   monet.Berkeley.Edu.

6.9.6. Hosts

	;
	;    @(#)ucb-hosts    1.2    (berkeley)    88/02/05
	;
	@            IN   SOA    ucbvax.Berkeley.Edu.   kjd.monet.Berkeley.Edu. (
	                         1988020501             ; Serial
	                         10800                  ; Refresh 
	                         1800                   ; Retry 
	                         3600000                ; Expire 
	                         259200 )               ; Minimum
	             IN   NS     ucbarpa.Berkeley.Edu.
	             IN   NS     ucbvax.Berkeley.Edu.
	localhost    IN   A      127.1
	             ; note that 127.1 is the same as 127.0.0.1; see inet(3n) 
	ucbarpa      IN   A      128.32.4
	             IN   A      10.0.0.78
	             IN   HINFO  VAX-11/780  UNIX
	arpa         IN   CNAME  ucbarpa
	ernie        IN   A      128.32.6
	             IN   HINFO  VAX-11/780  UNIX
	Ucbernie     IN   CNAME  ernie
	monet        IN   A      128.32.7
	             IN   A      128.32.130.6
	             IN   HINFO  VAX-11/750  UNIX
	Ucbmonet     IN   CNAME  monet
	ucbvax       IN   A      10.2.0.78
	             ; 128.32.10 means 128.32.0.10; see inet(3n) 
	             IN   A      128.32.10
	             ; HINFO and WKS are widely unused, 
	             ; but we'll show them as examples. 
	             IN   HINFO  VAX-11/750  UNIX
	             IN   WKS    128.32.0.10 TCP ( echo telnet discard sunrpc sftp 
	uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois 
	mtp pop rje finger smtp supdup hostnames domain nameserver )
	vax          IN   CNAME  ucbvax
	toybox       IN   A      128.32.131.119
	             IN   HINFO  Pro350      RT11
	toybox       IN   MX     0  monet.Berkeley.Edu.
	csrg         IN   MX     0  Ralph.CS
	             IN   MX     0  Zhou.CS
	             IN   MX     0  Painter.CS
	             IN   MX     0  Riggle.CS
	             IN   MX     0  Terry.CS
	             IN   MX     0  Kevin.CS

Перевод A.S.Plotnikov, 1998