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

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

domain       Berkeley.Edu

Более старые сервера имен используют эту информацию когда они получают запрос на имя без ". ", которое не известно. Более новые понимают, что библиотека определителя добавит его собственное понимание "домена по умолчанию (default domain) " к любому неопределенному имени. На самом деле сервер имен может быть скомпилирован с поддержкой директивы domain в файле загрузки, по умолчанию пропуская ее, и мы очень рекомендуем не использовать ее. Если вы все же используете это, клиенты находящиеся вне вашего локального домена будут посылать к вам запросы об неопределенных именах и будет происходить столкновения определения вашего домена с их. Наиболее подходящее место для использования этой функции - это клиент, в его файле /etc/resolv.conf (или равнозначном). Использование директивы domain в вашем загрузочном файле сбивает всех с толку.

Директива directory определяет каталог, в котором должен работать сервер имен и разрешает использование для остальных имен файлов в загрузочном файле относительных путей. Может быть использована только одна директива directory и она должна быть дана до всех остальных директив, определяющих имена файлов.

       directory        /var/named

Если у вас больше чем пара файлов, с которыми должен работать named, вы можете поместить эти файлы в каталог типа /var/named и применить соответствующую команду directory. Главная цель этой команды - удостовериться, что named находится в соответствующем каталоге, когда пытается включить файлы с относительным путем в $INCLUDE, а также позволить named работать в том месте, где он может отбросить корку (dump core) если ему вдруг станет плохо.

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

primary        Berkeley.Edu   ucbhosts

Первое поле говорит нам, что сервер является первичным для зоны, описанной во втором поле. Третье поле является именем файла, из которого нужно читать данные.

Вышесказанное подразумевает, что зона, которую вы определяете есть зона класса IN. Если вы хотите определить другой класс, вы можете добавить /class к первому полю, где class - это целое число или стандартное символьное представление класса. Например, строка для первичного сервера зоны класса hesiod выглядит так:

primary/HS         Berkeley.Edu    hesiod.data

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

Строка для вторично сервера аналогична первичному за исключением того, что она перечисляет адреса других серверов (обычно первичных), от которых будут получены данные о зоне.

secondary     Berkeley.Edu   128.32.0.10  128.32.0.4  ucbhosts.bak

Первое поле говорит о том, что это вторичный сервер для зоны описанной во втором поле. Два сетевых адреса определяют сервера имен, на которых имеются данные для этой зоны. Нужно отметить, что как минимум один из них будет первичным, и, пока вы используете какой-либо другой протокол вместо IP/DNS для механизма передачи зоны, остальные будут другими вторичными серверами. Вытягивание данных с других вторичных серверов на ваш вторичный сервер обычно не очень хорошо, так как происходит задержка в распространении изменений в зоне. Можно целенаправленно использовать много адресов в описании secondary, когда первичный сервер имеет много сетевых интерфейсов и, соответственно, много адресов. Вторичный сервер получает свои данные через сеть от одного из перечисленных серверов. Адреса серверов пробуются в порядке перечисления. После списка первичных серверов прописано имя файла, данные о зоне будут записаны в этот файл. Когда сервер запускается в первый раз, данные загружаются, если это возможно, из этого файла, а первичный сервер опрашивается по поводу того, не устарели ли эти данные. Нужно отметить, что перечисление вашего сервера как вторичного не необходимо -- родительская зона должна делегировать полномочия вашему серверу, как первичному, как и для остальных вторичных, или вы будете перекачивать всю зону; ни один другой сервер не будет иметь причины опрашивать ваш по поводу зоны пока в родительской зоне он не будет перечислен как сервер для зоны.

Как и в случае первичного для класса, отличного от IN, вы должны определять вторичный сервер добавлением /class к ключевому слову secondary, например secondary/HS.

Строка для поддельного сервера аналогична вторичному. (Эта возможность появилась как экспериментальная в версии 4.9.3.)

    stub   Berkeley.Edu       128.32.0.10  128.32.0.4  ucbhosts.bak 

Первое поле говорит о том, что сервер является поддельным сервером для зоны описанной во втором поле.

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

  

    primary        CSIRO.AU       csiro.dat
    stub           dms.CSIRO.AU   130.155.16.1  dms.stub 
    stub           dap.CSIRO.AU   130.155.98.1  dap.stub

Все сервера, включая "только кэширующие " сервера, для инициализации кэша сервера имен должны иметь в загрузочном файле строку типа:

  

    cache       .             root.cache

В ваших файлах кэша не пишите ничего кроме информации о корневом сервере.

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

Вместе с первичным и вторичным, вы можете указать вторичный сервер для класса отличного от IN добавлением к ключевому слову cache слова /class, например class/HS.

Любой сервер иожет использовать пересыльщиков. Пересылка - это еще одна возможность сервера при обработке рекурсивных запросов от имени других систем. Команда forwarders указывает пересыльщика по его адресу в internet:

  

    forwarders       128.32.0.10   128.32.0.4

Имеются две большие причины, чтобы так делать.

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

Работа "пересыльщиков " состоит в том, чтобы соотнести некоторые фиксированные адреса со списком серверов имен, которые нужно пробовать при каждом запросе. Обычно этот список состоит только из серверов с более высокой властью, обнаруженных через NS записи для соответствующего домена. Если пересыльщики не отвечают, то пока директива slave не была дана, будут опрошены непосредственно соответствующие сервера для областей.

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

  

     options forward-only 

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

Так, в то время как forwardres использует адреса из "списка серверов" для каждого запроса, options forward-only заставляет "список серверов" содержать только те адреса, которые перечислены в объявлении forwarders. Небрежное использование директивы options forward-only может вызывать действительно ужасные циклы пересылки, так как вы могли бы закончить запросы пересылки к некоторому набору хостов, которые также являются подчиненными, а один или несколько из них могли бы пересылать запросы обратно к вам.

Использование директивы options forward-only должно быть очень осторожным. Обратите внимание, что то же самое поведение может быть достигнуто использованием директивы slave.

Разделение данных BIND на авторитативные (зоны) и неавторитативные (кэша) всегда было несколько слабо, и, как известно возможно загрязнение вышеупомянутых через последние. Один из способов предотвратить это, также как и сохранить память на серверах поддерживающих множество авторитативных данных (например корневых серверах) состоит в том, чтобы делать такие сервера " нерекурсивными". Это может быть достигнуто использованием в загрузочном файле директивы

  

     options      no-recursion

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

Нерекурсивный сервер может быть проименован в NS RR, но не может быть указан в файле resolv.conf.

Если файловая система, содержащая ваш файл syslog имеет достаточно много места, то вы можете рассмотреть использование в вашем загрузочном файле директивы

  

           options        query-log

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

BIND по умолчанию не поддерживает обратные запросы, и это, как известно, может вызывать проблемы для некоторых операционных систем микроЭВМ и для более старых версий инструмента nslookup. Вы можете решить, что намного лучше, если вместо ответа "operation not implemented", named должен обнаруживать наиболее общие обратные запросы и отвечать на них поддельной информацией; конечно же лучше произвести обновление ваших клиентов, чтобы прекратить зависимость от обратных запросов, но если это не возможно, вы должны использовать эту директиву в вашем загрузочном файле

  
    
         options    fake-iquery

ОБРАТИТЕ ВНИМАНИЕ: ответы фактически поддельны, они содержат квадратные скобки ISO8859 ([ и ]), так что ваши клиенты не будут способны сделать что-нибудь полезное с этими ответами. Наблюдалось, что ни один клиент никогда не делал что-нибудь полезное даже с реальными ответами на обратные запросы.

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

  
    
        limit   <name>   <value>

Ограничения и их значения по умолчанию выглядят так:

  

        limit  transfers-in  10

При этом число означает количество одновременных процессов named-xfer которые BIND может запустить. Если ваш вторичный сервер имеет сотни или тысячи поддерживаемых зон, то более высокие числа могут привести к более быстрой сходимости к первичным серверам,но установка слишком высокого значения может привести к очень высокой загрузке сервера и пожиранию ресурсов, таких как ширина пропускания сети или свопингового пространства. ОБРАТИТЕ ВНИМАНИЕ: это ограничение может быть выражено пдирективой max-fetch NN.

  

       limit   transfers-per-ns  2

Это число означает количество процессов named-xfer, которые может инициировать BIND к любому заданному серверу имен. В большинстве случаев вы не должны изменять это число. Если ваш вторичный сервер тащит сотни или тысячи зон с одного первичного сервера, увеличение transfers-per-ns можеть ускорить сходимость. Это число нужно держать как можно меньшим, во избежание большой загрузки и пожирания ресурсов на первичном сервере.

Большинство систем имеют квоты, ограничивающие размер так называемого "сегмента данных", где BIND держит все авторитативные данные и кэш. BIND будет поступать субоптимально (возможно даже при завершении работы) если он работает при этой квоте. Если ваша система поддерживает системный вызов, изменяющий эту квоту для определенного процесса, вы можете попросить BIND использовать этот системный вызов посредством директивы limit datasize NN. Значение заданное здесь может быть задано добавлением k для 1024X, m для (1024^2)X, и g для (1024^3)X. В 1995г., все корневые сервера использовали limit datasize 64m.

Это может быть случай, который ваша организация не желает выдавать полные списки ваших хостов кому угодно в Inernet, кто может достичь ваших серверов имен. Хотя пока это все еще возможно для людей "итерировать" через ваш диапазон адресов, ища записи PTR и формируя список ваших хостов "медленным " " способом, поэтому все еще выглядит резонным ограничить ваш экспорт зон через протокол передачи зон. Чтобы ограничить список соседей могущих брать зоны с вашего сервера, используйте директиву xfrnets.

Эта директива имеет такой же синтаксис, что и forwarders, за исключением того, сто вы можете перечислить сетевые адреса в добавление к адресам хостов. Например, если вы хотите разрешить доступ к передаче зон с вашего сервера только хостам сети класса A с номером 16, вы можете использовать директиву

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

что разрешит только хосту 16.1.0.2 передавать зоны от вас. Заметьте, что не должно быть ни одного пробела вокруг знака "& ", представляющего собой сетевую маску.

Директива xfrnets для совместимости с промежуточными выпусками BIND 4.9. также может быть задана как tcplist.

Если имеется множество адреса, доступных для сервера имен, с которыми захочет контактировать BIND, BIND сначала будет пробовать те, которые он считает "самыми близкими". "Близость" определяется в терминах похожести по адресу; то-есть если один из адресов находится в той же самой подсети что и некоторый интерфейс хоста, то первым будет опробован этот адрес. Если это не получится, то затембудет попробован адрес, находящийся в той же сети. Если и это провалится, и если в файле named.boot не была задана директива sortlist, то адреса будут опробованы в более или менее произвольном порядке. Директива sortlist имеет синтаксис, подобный forwarders, xfrnets, и bogusns - вы задаете ему список сетей в виде xxx.xxx.xxx.xxx, и он использует их при "предпочтении" одних серверов имен перед другими. Если никакая явная маска не обеспечивается каждым элементом sortlist , то будет сделан вывод основанный на битах адреса старшего разряда.

Если вы находитесь в сети класса C, имеющей сеть класса B вами и остальным Internet, вы могли бы попробовать увеличить удачу сервера имен в получении ответов, перечислив сеть класса B в директиве sortlist. Это должно иметь эффект при опробовании "ближайших" серверов перед более "удаленными". Обратите внимание, что это поведение является новым, и появилось начиная с, BIND 4.9.

Другой и более старый эффект директивы sortlist должен заставить, BIND сортировать записи типа A в любом генерируемом ответе, чтобы поместить те, которые имеются в sortlist перед остальными. Это не настолько полезно, как вы могли бы подумать, так как многие клиенты будут пересортировывать записи типа A в произвольном порядке или используя "магазинный порядок" (LIFO); также учтите то, что сервер будет способен догадаться о топологии сети клиента, и таким образом не будет способен точно упорядочить "близость" ко всем возможным клиентам. Выполнение упорядочения в разрешителе ясно выше.

В реальной практике, эта директива используется очень редко, так как это жестко привязывает быстро меняющуюся информацию; сеть, которая "близка" сегодня, может быть "отдалена" уже в следующем месяце. Так как BIND создает кэш времен ответа удаленных серверов имен, то он будет быстро сходиться на "приемлемом" поведении, которое не означает "оптимальное", но почти то же самое. Будущие направления развития BIND, включают выбор адресов, основываясь на метриках локальных интерфейсов (хостах, имеющих больше чем один интерфейс) и, возможно, на информации из таблицы маршрутизации. Мы не собираемся решать обобщенную проблему "multihomed" хостов, но мы должны быть способны сделать что-то получше чем то,что мы имеем сейчас. Аналогично, мы надеемся увидеть библиотеку разрешителя на более высоком уровне, сортирующую ответы на основе информации о топологии, существующей только на клиентском хосте.

Иногда случается, что некоторый удаленный сервер имен становится "плохим". Вы можете указать вашему серверу имен отказаться слушать или задавать вопросы к конкретным серверам имен, перечислив их в директиве bogusns в вашем файле named.boot. Эта директива имеет тот же синтаксис что и forwarders, xfrnets, и sortlist -вам нужно только задать ему список адресов Internet в виде xxx.xxx.xxx.xxx. Обратите внимание, что зоны, делегируемые на такие сервера не будут доступны для клиентов ваших серверов; таким образом вы должны использовать эту директиву умеренно или вообще не использовать.

Если ваш сервер является вторичным для множества зон, вы можете найти удобным расчленить ваш файл named.boot на статическую часть, которая врядли когда-либо изменится (в нее могли бы войти директивы типа directory, sortlist, xfrnets и cache), и динамические части, которые изменяются достаточно часто (все ваши директивы primary могли войти в один файл, а все директивы secondary - в другой файл - и любой из них, или оба эти файла могли быть вытащены автоматически от некоторого соседа так, чтобы они могли изменить ваш список вторичных зон без вашего активного вмешательства). Вы можете выполнять это посредством директивы include, которая берет в качестве параметра только одно имя файла. Не нужны никакие кавычки вокруг имени файла. Имя файла будет оценено после того, как сервер имен изменит рабочий каталог на тот, что определен директивой directory, поэтому вы можете использовать относительные имена, если ваша система их поддерживает.

Файл конфигурации называется /etc/resolv.conf. Этот файл обозначает сервера имен в сети, к которым нужно послать запросы. Разрешитель будет пробовать установить контакт с сервером имен на localhost, если он не сможет найти файл конфигурации. В любом случае вы должны установить файл конфигурации на каждом хосте, так как это - единственный рекомендуемый способ определить домен по умолчанию на системном уровне, и вы можете записать в него адрес локального хоста, если на нем работает сервер имен. Будет вполне резонно создать этот файл в случае если у вас работает локальный сервер, так как его содержимое будет кэшироваться каждым клиентом разрешителя, когда клиент делает первый вызов программы разрешителя.

Файл resolv.conf содержит директивы, по одной в каждой строчке, в следующей форме:

; комментарий
# другой комментарий
domain local-domain 
search search-list 
nameserver server-address 
sortlist sort-list 
options option-list

Хотя бы одна из директив domain или search должна быть дана, хотя бы один раз. Если дана директива search, то первый элемент в заданном списке поиска (search-list) перевесит любой ранее определенный local-domain. Директива nameserver может быть дана до трех раз; все дополнительные директивы nameserver будут игнорированы. Если строка будет начинаться с ";" или "#", то эта строка будет считаться комментарием; нужно отметить, что комментарии не были позволены в ранних версиях разрешителя (тех что были включены в BIND версий младше 4.9) - так что если версия разрешителя вашего продавца поддерживает комментарии, то он в самом деле очень расторопен.

Local-domain будет добавлен к любому запросу, не содержащему ".". local-domain может быть обойден на уровне процессов установкой переменной окружения LOCALDOMAIN. Нужно отметить, что обработка local-domain может быть отключена установкой опции в разрешителе.

Search-list - это список доменов, которые пробуются, по порядку, для имен, не содержащих ".". Обработка search-list может быть отключена установкой опции в разрешителе. Также отметьте, что переменная окружения "LOCALDOMAIN" может подавить search-list на уровне процессов.

Адреса серверов (server-address) собираются вместе и затем используются как назначение по умолчанию запросов, генерируемых через разрешитель. Другими словами, таким образом вы можете сказать разрешителю, какие сервера имен он должен использовать. Для определенных клиентских приложений существует возможность обойти этот список, и она обычно осуществляется внутри сервера имен (который в то же самое время и есть клиент разрешителя) и в тестовых программах типа nslookup. Нужно отметить, что если вы хотите перечислить локальный хост в файле конфигурации разрешителя, вы лучше всего должны использовать его первичный адрес в Internet, чем псевдоимя локального хоста типа 127.0.0.1 или 0.0.0.0. Это необходимо из-за ошибки в сетевом коде некоторых версий BSD при обработке соединенных сокетов SOCK_DGRAM. Если вы должны использовать псевдоадрес, то лучше всего вместо 127.0.0.1 использовать 0.0.0.0 (или просто "0"), впрочем, вы предупреждены, что в зависимости от типа вашего сетевого кода BSD, оба из них способны на ошибку, какждый по-своему. Если реализация IP на вашем хосте не создает короткозамкнутый маршрут между интерфейсом по умолчанию и петлевым (loopback) интерфейсом, то вы можете добавить статический маршрут (например в /etc/rc.local) это делается так:

route add myhost.domain.name localhost 1

Sort-list - это список пар IP адресов и сетевых масок. Адреса возвращаемые процедурой gethostbyname сортируются в порядке определенном этим списком. Любые адреса, которые не соответствуют парам адресов и сетевых масок будут возвращены после всего. Сетевая маска опциональна, и если она не определена, будет использована натуральная сетевая маска.

Option-list - это список опций, каждая из которых подавляет какую-либо из внутренних переменных разрешителя. В настоящее время поддерживаются следующие опции:

 
debug

выставляет бит RES_DEBUG в _res.options.

 
ndots:n

выставляет более низкий порог (измеряемый в "количестве точек") в именах заданных res query(), так что имена с как минимум этим количеством точек будут опробованы как абсолютные имена, прежде чем будет произведена обработка local-domain или search-list. По умолчанию эта внутренняя переменная равна "1".

6.3.1. root.cache

Сервер имен должен знать сервера, которые являются авторитарными серверами имен для корневого домена сети. Чтобы это сделать, мы должны заполнить кэш сервера имен адресами этих авторитарных серверов имен. Расположение этого файла определено в файле начальной загрузки. Этот файл использует Стандартный Формат Записи Ресурса (иначе называемого Masterfile Format) описываемого далее в этом документе.

Имеется два стандартных файла для описания данных для домена. Это hosts и host.rev. Эти файлы используют Стандартный Формат Записи Ресурса, описываемый далее в этом документе. Нужно отметить, что имена файлов выбраны произвольно; многие сетевые администратопы предпочитают называть свои файлы зон по именам содержащихся в них доменов, особенно в усредненном случае, когда данный сервер является первичным и/или вторичным для множества различных зон.

Этот файл содержит все данные о машинах в этой зоне. Местонахождение этого файла определено в файле начальной загрузки.

Этот файл определяет домен IN-ADDR.ARPA. Это специальный домен для того, что бы можно было преобразовывать адреса в имена. Так как адреса хостов в Internet не входят в границы домена, этот специальный домен был сформирован для того, чтобы можно было производить обратное преобразование. Домен IN-ADDR.ARPA имеет четыре метки, упреждающие его. Эти метки соответствуют четырем октетам адресов Internet. Все четыре октета должны быть описаны, даже если октет содержит только нули. Адрес Internet 128.32.0.4 находится в домене 4.0.32.128.IN-ADDR.ARPA. Эта перестановка адреса очень неудобна для чтения, но позволяет естественное группирование хостов в сети.

Этот файл определяет запись PTR для локального петлевого интерфейса (loopback interface), более известного как local-host, чей сетевой адрес 127.0.0.1. Местонахождение этого файла определяется в файле начальной загрузки. Для правильной работы каждого сервера имен жизненно важно, чтобы адрес 127.0.0.1 имел запись PTR указывающую обратно на имя "localhost.". Имя этой записи PTR всегда "1.0.0.127.IN-ADDR.ARPA". Это просто необходимо, если вы хотите, чтобы пользователи могли использовать опознавание имени хоста по имени "localhost" (в hosts.equiv или ~/.rhosts). Как связанная с этой записью PTR, в каждом домене, содержащем хосты должна существовать запись "localhost.my.dom.ain" A (с адресом 127.0.0.1). "localhost." потеряет последнюю точку, которая требутся для 1.0.0.127.in-addr.arpa; тогда опции разрешителя DEFNAMES и/или DNSRCH заставят оценить "localhost" как имя хоста в локальном домене.

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

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

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

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

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

{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.

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

 
{name}   {ttl}   addr-class   A    address
  
ucbarpa          IN           A    128.32.0.4
                 IN           A    10.0.0.78

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

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

                  IN          HINFO   VAX-11/780  UNIX

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

 
{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 в большинстве доменов.

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

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

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

 
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 к этому доменному имени.

 
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" - очень тонкое дело, поэтому вы должны быть очень осторожны с ними.

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

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

 
owner   {ttl}  addr-class   RP    mbox-domain-name   TXT-domain-name

franklin       IN           RP    ben.franklin.berkeley.edu. sysadmins.berkeley.edu.

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

 
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 все еще экспериментальна; не все сервера имен поддерживают или распознают ее.

 
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 все еще экспериментальна; не все сервера поддерживают или распознают ее.

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

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

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

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

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

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

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

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

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

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

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все еще находится на стадии эксперимента.

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

; 
; 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.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