A - Адрес

{name} {ttl} addr-class A address

ucbarpa IN A 128.32.0.4 IN A 10.0.0.78

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

Список рассылки очень помог нам;

Список рассылки очень помог нам; если бы не их помощь, этот выпуск не был бы готов до сих пор. Особые благодарности к Robert Elz, Don "Truck" Lewis, Bob Halley, Mark Andrews, Berthold Paffrath, Ruediger Volk, и Peter Koch.

Digital Equipment Corporation, Hewlett Packard, Silicon Graphics, и SunSoft обеспечили нас оборудованием для окончательного тестирования; это сделало этот выпуск намного более стабильным, чем он был бы. Если вы дадите нам взаймы еще оборудования мы будем очень благодарны - если вы поставляете системы и хотите чтобы BIND работал на вашей платформе, а также хотите одолжить немного старого и поношенного оборудования для этих целей, напишите мне по адресу () чтобы мы могли встретиться.

Особые благодарности Internet Software Consortium за финансирование этой работы. Если ваша организация хочет оказать финансовую помощь будущим выпускам BIND и другого свободно распространяемого программного обеспечения для широкого использования в Internet, обращайтесь по .

в U. C. Berkeley зато,

Множество благодарностей пользователям в U. C. Berkeley зато, что они падали во множество дыр во время интеграции BIND в систему, так что остальные теперь будут защищены от травм. Я очень признателен Jim McGinness и Digital Equipment Corporation за то, что он разрешил потратить большинство моего рабочего времени на этот проект.

Ralph Campbell, Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss и всем остальным в DARPA Internet кто был вовлечен в разработку BIND. Всем членам изначального проекта BIND, Douglas Terry, Mark Painter, David Riggle и Songnian Zhou.

Anne Hughes, Jim Bloom and Kirk McKusick и многим другим, кто просмотрел этот документ, давая хорошие советы.

Эта работа была спонсирована Defense Advanced Research Projects Agency (DoD), Arpa Order No. 4871 консультирована Naval Electronics Systems Command по контракту No. N00039-84-C-0089. Все точки зрения и заключения в этом документе принадлежат авторам и не должны быть интерпретированы как официальная политика, или отнесены к Defense Research Projects Agency, Американскому Правительству, или Digital Equipment Corporation.

тестеров была невероятно помогла нам

Группа альфа- тестеров была невероятно помогла нам в поиске ошибок и многом другом, и была очень терпелива. Я хочу принести особую благодарность Brian Reid из Digital Equipment corporation за финансирование этой работы. Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, и многие другие очень помогли нам. Особое спасибо Phil Almquist, кто начал этот проект и дал нам большое количество кода, а так же исправил несколько самых плохих ошибок.

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

Безопасность

В этой части рассматриваются некоторые известные недостатки различных версий BIND. Некоторые из них были использованы в прошлом при атаках серверов имен.

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

alias {ttl} addr-class CNAME Canonical-name

ucbmonet IN CNAME monet

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

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

Домен

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

domain Berkeley.Edu

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

/Etc/hosts

Библиотечный вызов gethostbyname() может определить, запущен ли named. Если определено, что named не запущен, то для разрешения адреса будет просмотрен файл /etc/hosts. Эта опция была добавлена для того, чтобы позволить ifconfig(8C) сконфигурировать локальные интерфейсы машины и обеспечить системному менеджеру доступ к сети пока машина находится в однопользовательском режиме (single user mode). Советуется прописать в /etc/hosts адреса локальных интерфейсов машины и парочку имен машин и адресов, чтобы системный менеджер смог использовать rcp для копирования файлов с другой машины когда система находится в однопользовательском режиме. Формат /etc/hosts не изменился. За дополнительной информацией смотри hosts(5). По причине медленности процесса чтения из /etc/hosts, не советуется использовать эту оцию, когда система нажодится в многопользовательском режиме.

/Etc/rclocal

Имя хоста (hostname) в /etc/rc.local должно быть назначено в стиле полного доменного имени с использованием hostname(1). Для запуска named во время загрузки системы в файл /etc/rc.local должно быть добавлено следующее:

if [ -f /usr/sbin/named ]; then /usr/sbin/named [options] & echo -n 'named' >/dev/console fi

обычно это прописывается сразу после строчек, запускающих syslogd. НЕ пытайтесь запустить named из inetd. Это будет постоянно перезапускать сервер имен и совершенно нарушит предназначение кэша.

Файл Загрузки

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

при компиляции named или указанием места его расположения в командной строке при запуске named.

Файлы

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

Файлы Данных Домена

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

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

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

IN HINFO VAX-11/780 UNIX

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

Hostrev

; ; @(#)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.

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

Перевод , 1998

| |

Hostsrev

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

$INCLUDE

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

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

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

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

Инициализация кэша

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

cache . root.cache

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

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

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

Internet

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

MILnet HOSTMASTER@NIC.DDN.MIL other HOSTMASTER@INTERNIC.NET

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

Каталог

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

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

directory /var/named

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

Кэширующий сервер

Все сервера являются кэширующими. Это означает, что сервер кэширует информацию, которую он получает до тех пор, пока срок действия данных не истечет. Кэширующий Сервер - это сервер, который не является авторитативным ни для какой зоны. Этот сервер обслуживает запросы и опрашивает другие сервера, отвечающие за необходимую информацию. Все сервера держат данные в своих кэшах до тех пор, пока срок действия данных не истечет, основываясь на поле TTL ("Времени жизни (Time To Live)"), которое поддерживается для всех записей ресурсов.

Конфигурация Разрешителя

Файл конфигурации называется /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".

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

Namedlocal

Этот файл определяет запись 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" как имя хоста в локальном домене.

Перевод , 1998

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

Настройка своего собственного домена

При установке домена, который будет относится к публичным сетям, администратор сайта должен обратиться в организацию ответственную за еть и запросить соответствующую форму регистрации домена. Организация, принадлежащая к различным сетям (например Internet и BITNET) должна быть зарегистрирована только в одной из сетей.

Ненужное склеивание

Ненужное склеивание при загрузке в сервер может привести к некорректным записям. Это может привести к соединениям, идущим на чужие машины.

Для предотвращения загрузки ненужного склеивания, все сервера зон должны обслуживаться сервером, а сервера родительских зон должны быть обновлены до BIND 4.9.3 или более позднего.

Нерекурсивные сервера

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

options no-recursion

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

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

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

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

IN NS ucbarpa.Berkeley.Edu.

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

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

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

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

Обсуждение

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

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

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

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

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

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

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

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

$ORIGIN

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

Отказ от обслуживания: атака Несогласованности TTL

Если вы все еще используете много значений TTL внутри RRset вы можете быть подвержены атаке отказа от обслуживания. BIND 4.9.5 и далее использует много значений ttl внутри RRset для отказа от явно плохих RRset. Рекомендуется произвести обновление до BIND 4.9.5 или более позднего на таком сервере для предотвращения загрузки множественных значений TTL и присоединения ответов, полученных через сеть.

Перевод , 1998

| |

Отказ от обслуживания: хэшевая дыра

В Сентябре 1996 COM TLD был подвержен атаке "отказ от обслуживания" вводом в DNS записи с последней меткой COM, восемью пробелами и COM. Это затронуло сервера BIND 4.9.4. Подобные атаки возможны на BIND 4.9.3 и BIND 4.9.3-P1.

Для избежания этой дыры рекомендуется использовать BIND 4.9.4-P1 или более поздние версии.

Отладка

Когда named работает неправильно, сначала посмотрите в /var/log/messages и проверьте его на сообщения записанные syslog. Затем пошлите ему сигнал и посмотрите, что произойдет. Пока вы не запустите его с опцией "-d", named очень мало что скажет в свой стандартный вывод или стандартную ошибку. Все что говорит named, он говороит в syslog.

SIGINT - Сбрасывает все текущие базы данных и кэш в /var/tmp/named_dump.db. Это может показать вам, были ли базы данных корректно считаны. Имя файла дампа может быть изменено переопределением DUMPFILE на другое имя при компиляции named.

Заметьте: следующие два сигнала работают только когда named собран с определенным DEBUG.

SIGUSR1 - Включает отладку. Каждый следующий сигнал SIGUSR1 увеличивает уровень отладки. Вывод идет в /var/tmp/named.run Имя этого отладочного файла может быть изменено определением DEBUGFILE до компилляции named.

SIGUSR2 - Выключает отладочный режим.

Для более подробной отладки, определите DEBUG при компилляции программ разрешителя в /lib/libc.a.

SIGWINCH - Переключает трассировку всех входящих запросов если named был скомпиллирован с определенным QRYLOG. Трассировка посылается в syslog, обычно она очень велика, но очень полезна для отслеживания проблем.

Для запуска с трассировкой всех запросов в командной строке определите флаг -q. Если вы введете программный протокол запросов, то может быть вам захочется проанализировать результаты используя статистический скрипт dnsstats stats в каталоге contrib.

SIGIOT - Сбрасывает статистические данные в /var/tmp/named.stats, если сервер собран с определенным STATS. Статистика добавляется к файлу.

Перевод , 1998

| |

Пересыльщики

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

forwarders 128.32.0.10 128.32.0.4

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

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

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

Перезагрузка

SIGHUP - Заставляет named перечитать named.boot и перезагрузить базу данных. Это очень полезно, когда вы делаете изменения в "первичном" файле данных и хотите чтобы внутренняя база данных named отражала сделанные изменения. Если вы "собрали" BIND с опцией FORCED_RELOAD, то SIGHUP даст еще и эффект внеплановой проверки серийных номеров всех "вторичных" зон, что может привести к передаче зон вне обычного графика. Обычно сравнение серийных номеров делается только через интервалы, определенные в записи SOA для зоны.

Первичный Сервис

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

primary Berkeley.Edu ucbhosts

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

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

primary/HS Berkeley.Edu hesiod.data

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

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

Подчиненные сервера

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

options forward-only

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

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

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

Подчиненный Сервер

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

не являются рекурсивными. Может быть один или более пересыльных серверов, которые будут опрошены по очереди, пока список не иссякнет. Подобная конфигурация (Подчиненного и перенаправителя) обычно используется, если вы не хотите позволять всем серверам определенного места взаимодействовать с остальными серверами Internet. Обычно это представляет собой некоторое количество рабочих станций и выделенную машину с доступом в Internet. Доступ в Internet для рабочих станций может быть административно запрещен. чтобы создать для рабочих станций видимость доступа в доменную систему Internet, рабочие станции могут быть Подчиненными серверами для выделенной машины, которая может пересылать запросы и взаимодействовать с другими серверами имен обслуживания запроса до того, как вернет ответ. Дополнительной пользой от использования возможности пересылки будет то, что центральная машина имеет более полный кэш с информацией по сравнению со всеми рабочими станциями. Использование режима Подчиненного сервера и пересылки более подробно обсуждается в описании команд файла загрузки named.

Нет никаких ограничений против объявления сервера как починенного даже если он имеет первичную и/или вторичную

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

Перевод , 1998

| |

Поддельные Сервера Имен

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

Поддельный Сервис

Строка для поддельного сервера аналогична вторичному. (Эта возможность появилась как экспериментальная в версии 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

Поддомены Существующих Доменов

Если вы хотите завести поддомен некоего существующего домена, вам нужно выйти на контакт с родительским доменом, прежде жем обращаться с запросом к вышеперечисленным регистраторам верхнего уровня. Должно быть соглашение о том, что registrar@domain или hostmaster@domain для любого данного домена всегда будет псевдонимом для регистратора этого домена (что-то аналогичное postmaster), но такого соглашения нет. В конце концов, вы можете попробовать и это, но сначала проверьте запись SOA для домена и пошлите сообщение "Ответственной Персоне" указанной там. Также вы можете попробовать whois.

Перевод , 1998

| |

Построение системы с сервером имен

BIND состоит из двух частей. Одна из них - это пользовательский интерфейс, называемый разрешитель (resolver), который состоит из группы программ, находящихся в библиотеке C /lib/libc.a. Другая - это сам сервер, называемый named. Это демон, работающий в фоновом режиме и обслуживает запросы на заданном сетевом порту. Стандартный порт для UDP и TCP определен в /etc/services.

в смысле, на русском языке)

Данный документ ( в смысле, на русском языке) появился в результате того, чтоя решил получше разобраться с BIND. Оформление в виде HTML в будущем будет несколько усовершенствовано. Супер-точности перевода не гарантирую, но основной смысл, я надеюсь, сумел донести. Особенно долго я думал над переводом слов resolver и forwarder. Если кто-то сможет предложить лучший перевод этих слов, чем это сделано здесь, то я обещаю произвести соответствующие замены во всем документе.
Против распространения не возражаю, единственное условие: оставить все как есть, не внося никаких изменений.
Приму любые конструктивные замечания и предложения, направляйте их на адрес .

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

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

Программы Разрешителя в libc

При построении вашей системы 4.3BSD вы можете построить библиотеку C или с использованием программ разрешителя сервера имен или с использованием программ просмотра таблиц хостов для разрешения адресов и имен хостов. По умолчанию разрешитель для 4.3BSD использует сервер имен. Новейшие ситемы BSD включают функциональные возможности и сервера имен и таблицы хостов с предпочтением отданным серверу имен, в случае если он работает на машине или существует файл /etc/resolv.conf.

Построение библиотеки C с использованием сервера имен изменяет работу функций gethostbyname(3N), gethostbyaddr(3N), и sethostent(3N). Сервер имен делает gethostent(3N) ненужной, потому что она не имеет никакого представления о следующей строке в базе данных. Эти библиотечные вызовы построены с библиотеками разрешителя, необходимыми для опроса сервера имен.

Разрешитель содержит функции построения запросных пакетов и обмену ими с серверами имен.

Перед построением библиотеки С 4.3BSD, установите переменную HOSTLOOKUP в /usr/src/lib/libc/Makefile равной named. Затем соберите и установите библиотеку C и компиллятор, после чего скомпиллируйте остальную часть системы 4.3BSD. Более подробную информацию вы можете найти в разделе 6.6 документа "Installing and Operating 4.3BSD on the VAX|".

Если ваша система не VAX| 4.3BSD, то возможно, что ваш поставщик уже включил поддержку разрешителя в поставляемую Библиотеку C. Вам нужно обратиться к документации поставщика чтобы найти, что нужно сделать, чтобы обеспечить поддержку разрешителя. Заметьте, что разрешитель вашего поставщика может быть устаревшим по отношению к тому, что поставляется с BIND, и что вы может быть захотите собрать и установить библиотеку разрешителя BIND, и ее включаемые файлы (include), в ваш системный путь компилляции/связей, так чтобы ваши собственные сетевые приложения могли использовать новейшие возможности.

Перевод , 1998

| |

Протоколирование Запросов

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

options query-log

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

Псевдоподдержка Обратных Запросов

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

options fake-iquery

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

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

PX - Указатель преобразование информации XRFC

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 различных типа правил преобразования:

преобразование из X.400 в RFC822 (определяется как "table 1 rules" в RFC1327) преобразование из RFC822 в X.400 (определяется как "table 2 rules" в RFC1327) кодирование 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 все еще экспериментальна; не все сервера поддерживают или распознают ее.

REFERENCES

[Birrell] Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D., "Grapevine: An Exercise in Distributed Computing." In Comm. A.C.M. 25, 4:260-274 April 1982.

[RFC819] Su, Z. Postel, J., "The Domain Naming Convention for Internet User Applications." Internet Request For Comment 819 Network Information Center, SRI International, Menlo Park, California. August 1982.

[RFC974] Partridge, C., "Mail Routing and The Domain System." Internet Request For Comment 974 Network Information Center, SRI International, Menlo Park, California. February 1986.

[RFC1032] Stahl, M., "Domain Administrators Guide" Internet Request For Comment 1032 Network Information Center, SRI International, Menlo Park, California. November 1987.

[RFC1033] Lottor, M., "Domain Administrators Guide" Internet Request For Comment 1033 Network Information Center, SRI International, Menlo Park, California. November 1987.

[RFC1034] Mockapetris, P., "Domain Names - Concept and Facilities." Internet Request For Comment 1034Network Information Center, SRI International, Menlo Park, California. November 1987.

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification." Internet Request For Comment 1035 Network Information Center, SRI International, Menlo Park, California. November 1987.

[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types." Internet Request For Comment 1101 Network Information Center, SRI International, Menlo Park, California. April 1989.

[RFC1123] R. Braden, Editor, "Requirements for Internet Hosts - Application and Support" Internet Request For Comment 1123 Network Information Center, SRI International, Menlo Park, California. October 1989.

[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and Mockapetris, P., "New DNS RR Definitions" Internet Request For Comment 1183 Network Information Center, SRI International, Menlo Park, California. October 1990.

[RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988)/ ISO10021 and RFC822" Internet Request For Comment 1327 Network Information Center, SRI International, Menlo Park, California. May 1992.

[RFC1664] Allocchio, C., Bonito, A., Cole, B., Giordano, S., Hagens, R., "Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables" Internet Request For Comment 1664 Network Information Center, SRI International, Menlo Park, California. August 1994.

[RFC1713] Romao, A., "Tools for DNS debugging" Internet Request For Comment 1713, also FYI27 Network Information Center, SRI International, Menlo Park, California. November 1994.

[Terry] Terry, D. B., Painter, M., Riggle, D. W., and Zhou, S., The Berkeley Internet Name Domain Server. Proceedings USENIX Summer Conference, Salt Lake City, Utah. June 1984, pages 23-31.

[Zhou] Zhou, S., The Design and Implementation of the Berkeley Internet Name Domain (BIND) Servers. UCB/CSD 84/177. University of California, Berkeley, Computer Science Division. May 1984.

[Mockapetris] Mockapetris, P., Dunlap, K, Development of the Domain Name System ACM Computer Communications Review 18, 4:123-133. Proceedings ACM SIGCOMM '88 Symposium, August 1988.

[Liu] Liu, C., Albitz, P., DNS and BIND O'Reilly & Associates, Sebastopol, CA, 502 pages, ISBN 0-937175-82-X 1992

Перевод , 1998

|

Rootcache

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

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

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

Сегментированные загрузочные файлы

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

Сервис имен

Основной функцией сервера имен является обеспечение информации об объектах сети посредством ответов на запросы. Спецификации такого сервера имен определены в RFC1034, RFC1035 и RFC974. Эти документы могут быть найдены в /usr/src/etc/named/doc в 4.3BSD или получены по ftp с . Так же рекомендуется почитать соответствующие manual pages, named(8), resolver(3), и resolver(5).

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

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

С сервером имен сеть может быть разбита на иерархию доменов. Пространство имен организовано как дерево в соответствии с организационными или административными границами. Каждый узел, называемый домен (domain), задан меткой, и имя домена есть объединение всех меток от корневого до текущего домена, перечисленных справа налево и разделенные точками. Метка должна быть уникальна внутри ее домена. Все пространство разбито на несколько областей, называемых зонами, каждая из которых начинается с домена и расширяется по ветвям домена, где начинаются другие зоны. зоны обычно представляют административные границы. Пример адреса хоста для хоста в University of California, Berkeley будет выглядеть так:

monet.Berkeley.EDU

Домен верхнего уровня для образовательных организаций EDU; Berkeley - это поддомен домена EDU, а monet - это имя хоста.

Перевод , 1998

| |

Сигналы

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

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.

Сортировка адресов

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

Стандартный Формат Записи Ресурса

Записи в файлах данных сервера имен называются записями ресурсов. Стандартный Формат Записи Ресурса (The Standard Resource Record Format (RR)) определен в RFC1035. Вот общее описание этих записей:

{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), и только в поле имени, а не в поле данных.

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

Типы серверов

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

Типы зон

"Зона" - это точка делегирования в дереве DNS. Она содержит все имена от конкретной точки "вниз", за исключением делегированных в другие зоны. "Точка делегирования" имеет одну или более NS записей в "родительской зоне", которые должны совпадать с эквивалентной NS записью в корне "делегированной зоны" (т.е., имя "@" в файле зоны).

Понимание разницы между "зоной" и "доменом" очень важно для нормальной работы сервера имен. Например, рассмотрим домен DEC.COM, который включает такие имена как POBOX1.PA.DEC.COM и QUABBIN.CRL.DEC.COM даже если зона DEC.COM включает только делегирование зон PA.DEC.COM и CRL.DEC.COM. Зона может входить конкретно в один домен, а также может включать только часть домена (оставшаяся часть которого может быть делегирована другим серверам имен). Говоря на техническом языке, каждое имя в дереве DNS является "доменом", даже если это "терминал", который не имеет "поддоменов". Каждый поддомен является доменом и каждый домен, кроме корневого, также является поддоменом. Эта терминология не интуитивна. Чтобы более полно понять трудности и тонкости предмета, вы можете почитать RFC 1033, 1034, и 1035.

Подразумевая, что BIND - это Сервер Имен Домена в основном будем иметь дело с понятием зона. Первичная (primary)

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

Каждая зона будет иметь один "первичный " (primary) сервер, который считывает содержимое зоны из некого локального файла, который редактируется человеком или автоматически генерируется из некоего другого локального файла, редактируемого человеком. Далее следует некое количество "вторичных " (secondary) серверов, загружающих содержимое зон используя IP/DNS протокол (что означает, что вторичные серверы будут соединятся с первичным и вытаскивать зоны используя IP/TCP). Этот набор серверов (первичный и все вторичные) должен быть описан в записях типа NS

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

Перевод , 1998

| |

TXT - Текст

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

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

Удаленный Сервер

Удаленный Сервер - это средство, позволяющее использовать сервер имен на рабочей станции или на машине с ограниченным объемом памяти и производительностью CPU. Используя его вы можете использовать все сетевые программы использующие сервер имен без запуска сервера на локальной машине. Все запросы обслуживаются сервером имен работающим на другой машине в сети. Хост, имеющий файл /etc/resolv.conf

перечисляющий только удаленные хосты и не имеющий локального сервера имен, иногда называется Удаленным Сервером (потому что настоящий сервер удаленный?), но намного чаще он называется просто "DNS клиент ". Такой тип хостов технически не "сервер ", так как он не имеет кэша и не отвечает на запросы.

Удаленный Сервер / Клиент 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

Управление доменом

Эта часть содержит информацию, необходимую для запуска, контроля и отладки named.

Установка Ограничений Сервера

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

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

xfrnets 16.0.0.0

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

xfrnets 16.1.0.2&255.255.255.255

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

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

/Var/run/namedpid

Когда named успешно запущен, он записывает свой идентификатор процесса (process id) в файл /var/run/named.pid. Это полезно для программ, которые захотят посылать сигналы в named. Имя этого файла может быть изменено переопределением PIDFILE на новое имя во время компилляции named.

Вставка данных в зону обслуживания

Версии BIND, предшествующие BIND 4.9.2 подвержены вставке записей в зоны обслуживания.

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

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

secondary Berkeley.Edu 128.32.0.10 128.32.0.4 ucbhosts.bak

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

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

The Berkeley Internet Name Domain

The Berkeley Internet Name Domain (BIND) представляет собой сервер имен Internet для BSD-подобных операционных систем. BIND состоит из сервера (или "демона " (daemon)) называемого named
и библиотеки определителя. Сервер имен - это сетевой сервис, который позволяет клиентам давать имена ресурсам или объектам и обмениваться этой информацией с другими объектами сети. Таким образом достигается распределенная система баз данных для объектов в компьютерной сети. Сервер BIND работает в фоновом режиме, обслуживая запросы на известном сетевом порту. Стандартный порт для UDP и TCP описывается в /etc/services. Определитель - это набор программ находящихся в системной библиотеке, обеспечивающей интерфейс, который могут использовать программы для доступа к сервисам имен домена.
BIND полностью интегрирован в сетевые программы BSD (4.3 и более поздние выпуски) для использования при хранении и получении имен и адресов хостов. Системный администратор может сконфигурировать систему для использования BIND вместо дальнейшего просмотра информации в таблице хостов в файле сетевых хостов /etc/hosts. По умолчанию, конфигурация для BSD использует BIND.
Перевод , 1998
|

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

6.9.1.3. Загрузочный файл для Кэширующего Сервера Имен

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

---

---