Статус документа
Этот документ представляет собой руководство для администратора домена по настройке сервера имен и поддержке связанной с доменом части иерархической базы данных. Предполагается знакомство читателя с системой доменных имен. Документ может распространяться без ограничений.
Благодарности
Этот документ представляет собой форматированный набор примечаний и выдержек из работ, указанных в конце документа. Упомянем отдельно работу Paul Mockapetris и Kevin Dunlap.
Введение
Для работы сервера имен требуется несколько файлов. Обычно сервер использует несколько стартовых (boot/startup) файлов, называемых также ремнями безопасности (safety belt). Один раздел будет содержать список возможных корневых серверов, которые данный сервер будет использовать для получения актуального списка корневых серверов. В другой части приводится список файлов зон, загружаемых сервером и содержащих вашу локальную информацию о доменах. Файл зоны обычно содержит все данные для отдельного домена. В этом руководстве описаны форматы данных, используемые в файлах зон, и предложены параметры для использования в некоторых полях.
Каждая реализация сервера имен может потребовать использования своих файлов. Файлы зон стандартизованы, но некоторые серверы могут потребовать иных стартовых файлов. Для получения нужной информации обратитесь к документации используемых вами программ. В приложении к данному документу приведен ряд конкретных примеров.
Если что-то покажется вам сложным или непонятным, обратитесь за дополнительной информацией к соответствующим RFC.
Зоны
Зона определяет содержимое смежной области доменного пространства, обычно ограниченной административно. Обычно используются раздельные файлы зоны для каждого домена. Содержащиеся в файле зоны данные образуют ресурсные записи (Resource Record или RR).
Вы можете помещать данные на свой сервер имен только при наличии у вас полномочий по администрированию домена. Вы не должны добавлять записи для чужих доменов (за исключением специальных glue-записей). Сервер имен при загрузке обычно читает файл со списком зон, которые должны быть загружены в его базу данных. Формат этих файлов не стандартизован и может отличаться для разных реализаций серверов имен. Стартовый файл обычно содержит для каждой зоны имя домена и имя файла, содержащего данные, которые должны быть загружены для этой зоны.
Корневые серверы
Резольверу при первой загрузке требуется найти корневые серверы. Когда резольвер загружается, он обычно читает список корневых серверов из файла.
Резольвер будет перебирать корневые серверы из списка, пытаясь связаться с каждым из них. При обнаружении корневого сервера резольвер будет запрашивать у него текущий список корневых серверов. После получения такого списка прочитанный из файла список корневых серверов будет отброшен и заменен актуальным списком.
Корневые серверы меняются достаточно редко. Вы можете можете получить текущий список корневых серверов от NIC, загрузив по протоколу FTP файл NETINFO:ROOT-SERVERS.TXT или послав почтовый запрос по адресу [email protected] На сегодняшний день (июнь 1987) список корневых серверов включает:
SRI-NIC.ARPA 10.0.0.51 26.0.0.73 C.ISI.EDU 10.0.0.52 BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 A.ISI.EDU 26.3.0.103
Записи о ресурсах (RR)
Записи в файлах данных для зон называются ресурсными записями (RR). Формат этих записей стандартизован в RFC-883 и RFC-973.
Стандартная форма RR имеет вид:
<name> [<ttl>] [<class>] <type> <data>
Запись состоит из нескольких полей, разделенных пробелами
- <name> — поле имени указывает, что доменное имя применимо к данной записи RR. В некоторых случаях поле имени может оставаться пустым и по умолчанию будет совпадать с полем имени в предыдущей RR.
- <ttl> — сокращение для Time To Live (время жизни). Это поле задает время, на которое резольверу следует кэшировать RR до того, как снова запросить эту запись у сервера имен. Если оставить поле TTL пустым, по умолчанию будет использоваться минимальное время, указанное в записи SOA (см. ниже).
- <class> — поле класса задает группу протокола. Если оставить это поле пустым, по умолчанию будет использоваться последний класс.
- <type> — поле типа указывает тип данной записи RR (описания типов приведены ниже).
- <data> — поле данных определяется по разному для каждого типа и класса данных. Форматы данных для часто используемых записей RR описаны ниже.
Доменная система не гарантирует сохранения порядка записей RR. Указание RR (например, множества адресных записей) в определенном порядке не гарантирует их использования в том же порядке. Регистр символов в именах и полях данных сохраняется при загрузке информации сервером имен. Все сравнения и просмотры в серверах имен не чувствительны к регистру (не различают строчных и прописных букв). Круглые скобки ( ) служат для группировки данных, не помещающихся в одну строку. Точка с запятой (;) указывает начало комментария (т. е. оставшаяся часть строки игнорируется сервером). Звездочка (*) служит для задания шаблонов. Знак @ обозначает текущее принятое по умолчанию значение доменного имени.
Имена
Доменное имя представляет собой последовательность меток, разделенных точками. Доменные имена в зоне могут быть одного из двух типов — абсолютные или относительные. Абсолютные имена являются полными доменными именами, в конце которых дополнительно поставлена точка. Относительные имена не завершаются точкой и к ним добавляется принятое по умолчанию доменное имя. По умолчанию обычно используется имя домена, указанное в загрузочном файле при загрузке каждой зоны. Доменная система позволяет использовать в именах любые 8-битовые символы. Хотя доменная система не вносит ограничений, другие протоколы (типа SMTP) ограничивают использование символов в именах. В силу таких ограничений рекомендуется использовать для имен хостов только следующие символы (и точки, в качестве разделителей):
"A-Z", "a-z", "0-9", дефис (-) и подчеркивание (_)
Время жизни (TTL)
Важное значение имеет выбор времени жизни TTL. Поле TTL задает время (в секундах), в течение которого резольвер будет использовать полученные от вашего сервера данные до того, как повторит запрос. При установке слишком малого значения сервер будет перегружен часто повторяющимися запросами. Если установлено слишком большое время жизни, после обновления информации она в течение некоторого времени останется неизвестной. Если оставить поле TTL пустым, по умолчанию будет взято время жизни из записи SOA для данной зоны.
Большая часть сведений о хостах изменяется очень редко. Хорошей практикой является установка большого значения TTL и его снижение перед внесением изменений. Вы можете устанав ливать для большинства случаев значение TTL от суток (86400) и до недели (604800). Если вы планируете в ближайшем будущем изменить те или иные данные, установите значение TTL для записи RR в диапазоне от часа до суток и сохраняйте это значение до внесения изменений, а потом вернитесь к первоначальному значению.
Отметим, что все записи RR с одинаковым именем, классом должны использовать одинаковые значения TTL.
Классы
Доменная система была разработана для работы независимо от протоколов. Поле класса используется для идентификации группы протоколов, к которой относится каждая запись RR.
При использовании протоколов TCP/IP поле класс должно иметь значение Internet, часто обозначаемое сокращением IN. Файл зоны должен содержать только записи RR одного класса.
Типы
Существует множество типов записей RR. Полный список вы сможете найти в спецификации DNS. Ниже приведен список наиболее часто используемых типов. Данные для каждого из этих типов описаны ниже в соответствующих параграфах.
| Обозначение | Описание | |
|---|---|---|
| SOA | Start Of Authority | Начало полномочий |
| NS | Name Server | Сервер имен |
| A | Internet Address | IP-адрес |
| CNAME | Canonical Name (nickname pointer) | Каноническрое имя (псевдоним) |
| HINFO | Host Information | Информация о хосте |
| WKS | Well Known Services | Хорошо известные службы |
| MX | Mail Exchanger | Обмен почтой |
| PTR | Pointer | Указатель |
SOA (Start Of Authority — начало полномочий)
<name> [<ttl>] [<class>] SOA <origin> <person> (
<serial>
<refresh>
<retry>
<expire>
<minimum> )
Запись SOA обозначает начало зоны, которая завершается следующей записью SOA.
- <name> — имя зоны.
- <origin> — имя хоста на котором хранится основной (master) файл зоны.
- <person> — почтовый адрес лица, ответственного за данную зону. Адрес форматируется подобно обычным почтовым адресам, но взамен символа @ используется nочка.
- <serial> — порядковый номер версии файла зоны. Этот номер должен возрастать при каждом внесении изменений в файл. (Общепринятым форматом серийного номера является YYYYMMDDnn, где YYYY указывает год, MM — месяц, DD — число и nn — порядковый номер изменений за текущие сутки. Такая нумерация при аккуратном обращении с полем обеспечивает постоянное возрастание значения номера.)
- <refresh> — период (в секундах), с которым вторичный (secondary) сервер имен просматривает основной сервер на предмет определения необходимости обновления. Разумным значением является 1 час (3600).
- <retry> — период(в секундах), с которым вторичный сервер имен будет повторять попытку после сбоя при проверке наличия обновлений. Разумно установить для этого поля значение 10 минут (600).
- <expire> — максимальное время использования данных вторичным сервером, после которого делается обязательное обновление. Хорошим значением является 3600000 секунд (около 42 дней).
- <minimum> — минимальное значение TTL в записях RR. Хорошим выбором для минимального времени жизни являются сутки (86400).
В каждой зоне должна быть только одна запись SOA. Пример такой записи показан ниже:
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400 ) ;minimum
NS (Name Server — сервер имен)
<domain> [<ttl>] [<class>] NS <server>
Запись NS указывает имя машины, обеспечивающей службу имен для отдельного домена. Имя, связанное с RR, является доменным именем, а в качестве данных для таких записей используется имя хоста, обеспечивающего сервис имен. Если машины SRI-NIC.ARPA и C.ISI.EDU обеспечивают серверы имен для домена COM, соответствующая строка будет иметь вид:
COM. NS SRI-NIC.ARPA.
NS C.ISI.EDU.
Отметим, что машины, обеспечивающие службу имен, не находятся в указанном домене. Для каждого сервера имен в домене должна использоваться отдельная запись NS. Отметим также, что в приведенном пример для второй записи NS по умолчанию используется доменное имя COM.
Записи NS для домена существуют как в самом домене, так и зоне, которая делегирует этот домен.
Приклеенная запись
Если сервер имен для домена находтся внутри этого домена, требуется использовать приклеенную (glue) запись, которая представляет собой RR типа A (адрес), указывающую адрес сервера имен. Glue-запись нужна только на сервере, делегирующем домен, но не в самом домене. В прив еденном ниже примере для домена SRI.COM сервером имен является KL.SRI.COM. В этом случае вслед за NS-записью должна располагаться приклеенная запись A.
SRI.COM. NS KL.SRI.COM. KL.SRI.COM. A 10.1.0.2
A (адрес)
<host> [<ttl>] [<class>] A <address>
Для записей типа A данными служит IP-flhtc d десятичном формате с разделением точками. Пример записи типа A приведен ниже:
SRI-NIC.ARPA. A 10.0.0.51
Для каждого адреса хоста должна использоваться одна запись типа A.
CNAME (каноническое имя)
<nickname> [<ttl>] [<class>] CNAME <host>
Запись CNAME используется для псевдонимов (nickname). Имя, связанное с RR является псевдонимом. Поле данных записи содержит официальное имя. Например, для машины SRI-NIC.ARPA можно создать псевдоним NIC.ARPA. В этом случае запись RR будет иметь вид:
NIC.ARPA. CNAME SRI-NIC.ARPA.
Не должно существовать никаких RR связанных с этим псевдонимом в том же классе записей. Псевдонимы полезны также при замене имени хоста. В этом случае просто созлается запись для нового имени и псевдоним — для старого.
HINFO (информация о хосте)
<host> [<ttl>] [<class>] HINFO <hardware> <software>
Запись HINFO дает информацию об отдельном хосте. Данные в этом случае представляют собой две фразы, разделенные пробелом. В перв ой фразе приводится описание оборудования (hardware), а во второй — программ хоста. Описание оборудования обычно включает (имя производителя и модель, разделенные дефисом (-). Вторая фраза обычно содержит название операционной системы хоста.
Официальные типы HINFO можно найти в последней версии RFC-3232 Assigned Numbers. Тип Hardware иногда называют Machine name (имя машины), а тип Software — System name (имя системы). Some sample HINFO records:
SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
WKS (Well Known Services — хорошо известные службы)
<host> [<ttl>] [<class>] WKS <address> <protocol> <services>
Записи WKS используются для перечисления хорошо известных служб (Well Known Services), обеспечиваемых хостом. WKS определяются для служб с номерами портов меньше 256. запись WKS перечисляет службы, доступные по отдельным адресам с использованием указанных протоколов. Обычно в качестве протоколов указывают TCP или UDP. Пример записи WKS для хоста, обеспечивающего одинаковый набор служб для всех адресов, приведен ниже:
SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP
WKS 10.0.0.51 UDP TIME
WKS 26.0.0.73 TCP TELNET FTP SMTP
WKS 26.0.0.73 UDP TIME
Официальные имена протоколов можно найти в последней версии RFC-3232 Assigned Numbers.
MX (Mail Exchanger — обмен почтой) (см RFC-974)
BAR.FOO.COM. MX 10 PO.FOO.COM.
Записи MX указывают куда должна доставляться почта для домена. Для каждого домена может присутствовать множество записей MX. Приоритеты доставки (почтовых серверов) определяются значением поля preference (0 указывает наиболее предпочтительный сервер). Допускается наличие нескольких записей с одинаковым уровнем приоритета. Хост BAR.FOO.COM для доставки почты через PO.FOO.COM может использовать запись MX:
BAR.FOO.COM. MX 10 PO.FOO.COM.
Хост BAZ.FOO.COM для доставки почты через три хоста может использовать записи:
BAZ.FOO.COM. MX 10 PO1.FOO.COM.
MX 20 PO2.FOO.COM.
MX 30 PO3.FOO.COM.
Если целая группа (домен) хостов не подключена к Internet, можно указать почтовый шлюз, который знает как доставить почту. Для передачи всей почты домена FOO.COM через почтовый шлюз можно указать:
FOO.COM. MX 10 RELAY.CS.NET. *.FOO.COM. MX 20 RELAY.CS.NET.
Отметим, что в записях MX можно использовать шаблон «*», для обозначения всех хостов домена FOO.COM, за исключением хоста FOO.COM.
IN-ADDR.ARPA
Структура имен в доменной системе имеет иерархическую форму, поэтому определение адреса по имени осуществляется путем перехода вниз по дереву имен. Поскольку индексирование ведется по именам, не существует простого способа выполнения обратной трансляции — определения имени хоста по его адресу.
Для упрощения обратной трансляции был создан домен, который использует адреса хостов как часть имени, которая указывает на данные для этого хоста. Таким способом обеспечивается возможность «индексирования» записей RR на основе адресов хостов. Такой домен отображения адресов получил название IN-ADDR.ARPA. В домене имеются субдомены для каждой сети на основе номеров сетей. Для согласованности и естественной группировки используются все 4 октета адреса хоста.
Наприм ер, сеть ARPANET имеет номер 10. Это означает, что соответствующий домен будет называться 10.IN-ADDR.ARPA. В этом домене существуют записи PTR с именем 51.0.0.10.IN-ADDR, указывающие на RR для хоста SRI-NIC.ARPA (он имеет адрес 10.0.0.51). Поскольку NIC входит также в MILNET (сеть 26, адрес 26.0.0.73), существует также запись PTR с именем 73.0.0.26.IN- ADDR.ARPA, указывающая на ту же запись RR для хоста SRI-NIC.ARPA. Формат укаазтелей PTR рассмотрен ниже и включает пример для NIC.
PTR
<special-name> [<ttl>] [<class>] PTR <name>
Записи PTR используются для обеспечения поддержки специальных имен, указывающих на некоторое место в дереве домена. В основном такие записи используются в записях IN-ADDR.ARPA для трансляции адресов в имена. Записи PTR должны использовать официальные имена и включение псевдонимов недопустимо.
Например, хост SRI-NIC.ARPA с адресами 10.0.0.51 и 26.0.0.73 будет иметь следующие записи в файлах обратной зоны для сетей 10 и 26:
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
Указатель шлюза (PTR)
Дерево IN-ADDR используется также для поиска шлюзов (маршрутизаторов) в отдельной сети. Для шлюзов используют такие же записи PTR, как для хостов (см. выше), но эти записи содержат дополнительные указатели PTR, используемые для нахождения шлюзов по номеру сети. Такие записи содержат только 1, 2 или 3 октета, как часть имени, зависящая от класса сети (A, B и C, соответственно).
Возьмем в качестве примера шлюз SRI-CSL, соединяющий три различных сети классов A, B и C. Этот шлюз будет иметь стандартные записи для хоста в зоне CSL.SRI.COM:
GW.CSL.SRI.COM. A 10.2.0.2
A 128.18.1.1
A 192.12.33.2
В дополнение к этому, в 3 различных зонах (одна для каждой сети) шлюз будет иметь одну из перечисленных ниже записей для указателей:
2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
Кроме того, в каждой из 3 зон будет присутствовать один из указателей местоположения шлюза:
10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
Рекомендации по настройке
Добавление субдомена
Для добавления нового субдомена в ваш домен выполните следующие операции:
- Создайте новый сервер имен и/или новый файл зоны.
- Добавьте запись NS для каждого сервера имен нового домена в файл зоны родительского домена.
- Добавьте нужные приклеенные записи RR.
Добавление хоста
Для добавления нового хоста в файл зоны:
- Отредактируйте файл зоны для домена, включающего хост.
- Добавьте запись для каждого из адресов хоста.
- При необходимости добавьте записи CNAME, HINFO, WKS и MX.
- Добавьте обратную запись IN-ADDR для каждого из адресов хоста в соответствующие файлы зон для каждой сети, в которую входит хост.
Удаление хоста
Для удаления хоста из файлов зоны:
- удалите все связанные с хостом записи из файла зоны для домена, включающего этот хост.
- Удалите все записи PTR из файлов зон IN-ADDR для каждой сети, в которую входит хост.
Добавление шлюзов
Для добавления шлюза выполните все операции по добавлению хоста.
- Добавьте запись PTR, указывающую на шлюз для каждой сети, в которую он входит.
Удаление шлюзов
Для удаления шлюза выполните все операции по удалению хоста.
- Удалите все записи PTR, указывающие на шлюз для каждой сети в которую входит шлюз.
Разрешение проблем
Ниже приведено несколько реком ендаций, которыми вы сможете воспользоваться при возникновении проблем, которые по вышему разумению связаны с сервером имен:
- Свяжитесь в частном порядке с отвечающим за домен человеком. Его адрес можно найти в записи SOA для домена.
- Свяжитесь официально с отвечающим за домен человеком.
- Узнайте в NIC имя отвечающего за домен человека и свяжитесь с ним. Вы можете также найти информацию о контактных лицах для домена на сервере NIC в файле NETINFO:DOMAIN-CONTACTS.TXT
- Свяжитесь с ответственным лицом родительского домена.
- Попросите у ответственного лица отключить домен.
Примеры конфигурационных файлов для доменов
Ниже приведены примеры файлов зон для типичных организаций (в качестве примера такой организации используется SRI). Компания SRI решила поделить свой домен SRI.COM на несколько субдоменов (по одному для каждой пожелавшей группы). Для этих субдоменов выбраны имена CSL и ISTC.
Отметим следующие моменты:
- в домене SRI.COM присутствуют как хосты, так и субдомены;
- имя CSL.SRI.COM относится к хосту и субдомену;
- все домены обслуживаются общей парой серверов имен;
- все хосты субдомена SRI находятся в подсети 128.18, за исключением хостов субдомена CSL, относящихся к сети 192.12.33;
- приведенный пример не соответствует какой-либо реальной сети.
Организация домена SRI
+-------+
| COM |
+-------+
|
+-------+
| SRI |
+-------+
|
+----------++-----------+
| | |
+-------+ +------+ +-------+
| CSL | | ISTC | | Hosts |
+-------+ +------+ +-------+
| |
+-------+ +-------+
| Hosts | | Hosts |
+-------+ +-------+
[Файл CONFIG.CMD]
Поскольку загрузочные файлы не стандартизованы, мы использовали здесь синтаксис псевдоконфигурационного файла.
load root server list from file ROOT.SERVERS load zone SRI.COM. from file SRI.ZONE load zone CSL.SRI.COM. from file CSL.ZONE load zone ISTC.SRI.COM. from file ISTC.ZONE load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
[Файл ROOT.SERVERS]
Для этого типа файлов текже отсутствует стандартизация.
;list of possible root servers SRI-NIC.ARPA 10.0.0.51 26.0.0.73 C.ISI.EDU 10.0.0.52 BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 A.ISI.EDU 26.3.0.103
[Файл SRI.ZONE]
SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870407 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of an hour
)
SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 KL.SRI.COM.
;SRI.COM hosts
KL A 10.1.0.2
A 128.18.10.6
MX 10 KL.SRI.COM.
STRIPE A 10.4.0.2
STRIPE A 128.18.10.4
MX 10 STRIPE.SRI.COM.
NIC CNAME SRI-NIC.ARPA.
Blackjack A 128.18.2.1
HINFO VAX-11/780 UNIX
WKS 128.18.2.1 TCP TELNET FTP
CSL A 192.12.33.2
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
MX 10 CSL.SRI.COM.
[Файл CSL.ZONE]
CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870330 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
CSL.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
A 192.12.33.2
;CSL.SRI.COM hosts
A CNAME CSL.SRI.COM.
B A 192.12.33.3
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.3 TCP TELNET FTP SMTP
GW A 10.2.0.2
A 192.12.33.1
A 128.18.1.1
HINFO PDP-11/23 MOS
SMELLY A 192.12.33.4
HINFO IMAGEN IMAGEN
SQUIRREL A 192.12.33.5
HINFO XEROX-1100 INTERLISP
VENUS A 192.12.33.7
HINFO SYMBOLICS-3600 LISPM
HELIUM A 192.12.33.30
HINFO SUN-3/160 UNIX
ARGON A 192.12.33.31
HINFO SUN-3/75 UNIX
RADON A 192.12.33.32
HINFO SUN-3/75 UNIX
[Файл ISTC.ZONE]
ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
870406 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
ISTC.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 SPAM.ISTC.SRI.COM.
; ISTC hosts
joyce A 128.18.4.2
HINFO VAX-11/750 UNIX
bozo A 128.18.0.6
HINFO SUN UNIX
sundae A 128.18.0.11
HINFO SUN UNIX
tsca A 128.18.0.201
A 10.3.0.2
HINFO VAX-11/750 UNIX
MX 10 TSCA.ISTC.SRI.COM.
tsc CNAME tsca
prmh A 128.18.0.203
A 10.2.0.51
HINFO PDP-11/44 UNIX
spam A 128.18.4.3
A 10.2.0.107
HINFO VAX-11/780 UNIX
MX 10 SPAM.ISTC.SRI.COM.
[Файл SRINET.ZONE]
18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870406 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
; SRINET [128.18.0.0] Address Translations
; SRI.COM Hosts
1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
; ISTC.SRI.COM Hosts
2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM.
6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM.
11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM.
201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM.
203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM.
3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.
; CSL.SRI.COM Hosts
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
[Файл SRI-CSL-NET.ZONE]
33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870404 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
; SRI-CSL-NET [192.12.33.0] Address Translations
; SRI.COM Hosts
2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
; CSL.SRI.COM Hosts
1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM.
4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM.
5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM.
7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM.
30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM.
31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM.
32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.
Приложение
Программа сервера имен BIND (Berkeley Internet Name Domain server) распространяется с ОС 4.3 BSD UNIX. В этом разделе описаны для специфичных для BIND файла — загрузочный файл и кэш-файл. BIND имеет также другие опции, файлы и спецификации, которые не описаны здесь. Более подробную информацию вы сможете найти в книге Name Server Operations Guide for BIND [1].
Загрузочный файл BIND обычно называется named.boot (он соответствует файлу CONFIG.CMD в разделе «Примеры»).
cache . named.ca primary SRI.COM SRI.ZONE primary CSL.SRI.COM CSL.ZONE primary ISTC.SRI.COM ISTC.ZONE primary 18.128.IN-ADDR.ARPA SRINET.ZONE primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE
Кэш-файл для BIND обычно называется named.ca (он соответствует файлу ROOT.SERVERS).
;list of possible root servers
. 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRI-NIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRL-AOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A.ISI.EDU. A 26.3.0.103
Приложение 1
Список корневых серверов (ftp://ftp.rs.internic.net/domain/named.root)
; 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 ; under anonymous FTP as ; file /domain/named.root ; on server FTP.INTERNIC.NET ; -OR- RS.INTERNIC.NET ; ; last update: Nov 01, 2007 ; related version of root zone: 2007110100 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc. ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 ; ; operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; operated by ICANN ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42 ; ; operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File
Литература
| [1] | Dunlap, K., «Name Server Operations Guide for BIND», CSRG, Department of Electrical Engineering and Computer Sciences, University of California, Berkeley, California. |
| [2] | Partridge, C., «Mail Routing and the Domain System», RFC-974, CSNET CIC BBN Laboratories, Январь 1986. |
| [3] | Mockapetris, P., «Domains Names — Concepts and Facilities», RFC-1034, USC/Information Sciences Institute, Ноябрь 1987. |
| [4] | Mockapetris, P., «Domain Names — Implementations Specification», RFC-1035, USC/Information Sciences Institute, Ноябрь 1987. |