{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), и только в поле имени, а не в поле данных.
Везде где встречается имя - в поле имени или в каких-либо полях содержащих имена - если имя не заканчивается на ".", то будет добавлен текущий источник (@). Это полезно для добавления текущего имени домена к данным, таким как имена машин, но может создать проблемы, если вы не хотите, чтобы это происходило. Хороший практический метод: если имя не находится в домене, для которого вы создаете файл данных, заканчивайте такое имя ".".
Строчка включений начинается с $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.
{name} {ttl} addr-class NS Name-servers-name
IN NS ucbarpa.Berkeley.Edu.
Запись Сервер Имен, 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, определяет имя или группу имен ответственных за хост. Обычно желательно, чтобы было возможно определить существо, ответственное за определенный хост. Когда этот хост находится в выключенном состоянии или работает неправильно, вы можете захотеть познакомиться слюдьми, кто может быть ответственнен за восстановление хоста.
Первое поле, 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 все еще экспериментальна; не все сервера имен поддерживают или распознают ее.
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 различных типа правил преобразования:
Все три типа правил преобразованич определены использованием Записи Ресурса типа 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
; ; 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
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
; ; 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
@ 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.
; ; @(#)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.
; ; @(#)ucb-hosts 1.2 (berkeley) 88/02/05 ; @ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. ( 1988020501 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 259200 ) ; Minimum IN NS ucbarpa.Berkeley.Edu. IN NS ucbvax.Berkeley.Edu. localhost IN A 127.1 ; note that 127.1 is the same as 127.0.0.1; see inet(3n) ucbarpa IN A 128.32.4 IN A 10.0.0.78 IN HINFO VAX-11/780 UNIX arpa IN CNAME ucbarpa ernie IN A 128.32.6 IN HINFO VAX-11/780 UNIX Ucbernie IN CNAME ernie monet IN A 128.32.7 IN A 128.32.130.6 IN HINFO VAX-11/750 UNIX Ucbmonet IN CNAME monet ucbvax IN A 10.2.0.78 ; 128.32.10 means 128.32.0.10; see inet(3n) IN A 128.32.10 ; HINFO and WKS are widely unused, ; but we'll show them as examples. IN HINFO VAX-11/750 UNIX IN WKS 128.32.0.10 TCP ( echo telnet discard sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) vax IN CNAME ucbvax toybox IN A 128.32.131.119 IN HINFO Pro350 RT11 toybox IN MX 0 monet.Berkeley.Edu. csrg IN MX 0 Ralph.CS IN MX 0 Zhou.CS IN MX 0 Painter.CS IN MX 0 Riggle.CS IN MX 0 Terry.CS IN MX 0 Kevin.CS
Перевод A.S.Plotnikov, 1998
Назад | Содержание | Вперед