Network Working Group M. Lottor
Request For Comments: 1033 SRI International
November 1987
Руководство администратора домена
DOMAIN ADMINISTRATORS OPERATIONS GUIDE
Статус документа
Этот документ представляет собой руководство для администратора домена по настройке сервера имен и поддержке связанной с доменом части иерархической базы данных. Предполагается знакомство читателя с системой доменных имен. Документ может распространяться без ограничений.
Благодарности
Этот документ представляет собой форматированный набор примечаний и выдержек из работ, указанных в конце документа. Упомянем отдельно работу Paul Mockapetris и Kevin Dunlap.
Введение
Для работы сервера имен требуется несколько файлов. Обычно сервер использует несколько стартовых (boot/startup) файлов, называемых также «ремнями безопасности». Один раздел будет содержать список возможных корневых серверов, которые данный сервер будет использовать для получения актуального списка корневых серверов. В другой части приводится список файлов зон, загружаемых сервером и содержащих вашу локальную информацию о доменах. Файл зоны обычно содержит все данные для отдельного домена. В этом руководстве описаны форматы данных, используемые в файлах зон, и предложены параметры для использования в некоторых полях1. Если что-то покажется вам сложным или непонятным, обратитесь за дополнительной информацией к соответствующим RFC.
Зоны
Зона определяет содержимое связной области доменного пространства, обычно ограниченной административно. Как правило используются раздельные файлы зоны для каждого домена. Содержащиеся в файле зоны данные образуют записи о ресурсах (RR2).
Вы можете помещать данные на свой сервер имен только при наличии у вас полномочий по администрированию домена. Вы не должны добавлять записи для чужих доменов (за исключением специальных склеивающих записей).
Сервер имен при загрузке обычно читает файл со списком зон, которые должны быть загружены в его базу данных. Формат этого файла не стандартизован и может отличаться для разных реализаций серверов имен. Стартовый файл обычно включает для каждой зоны имя домена и имя файла, содержащего данные, которые должны быть загружены для этой зоны.
Корневые серверы
Преобразователю3 при первой загрузке требуется найти корневые серверы. Когда преобразователь загружается, он обычно читает список корневых серверов из файла.
Преобразователь будет перебирать корневые серверы из списка, пытаясь связаться с каждым из них. При обнаружении корневого сервера преобразователь будет запрашивать у него текущий список корневых серверов. После получения такого списка прочитанный из файла список корневых серверов будет отброшен и заменен актуальным списком.
Корневые серверы меняются достаточно редко. Вы можете можете получить текущий список корневых серверов от NIC, загрузив по протоколу FTP файл NETINFO:ROOT-SERVERS.TXT4 или послав почтовый запрос по адресу NIC@SRI-NIC.ARPA5.
На сегодняшний день6 список корневых серверов включает7:
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). Формат этих записей стандартизован в RFC 883 и RFC 9738. Стандартная форма RR имеет вид:
<name> [<ttl>] [<class>] <type> <data>
Запись состоит из нескольких полей, разделенных пробелами9.
- <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> – почтовый адрес лица, ответственного за данную зону. Адрес форматируется, подобно обычным почтовым адресам, но взамен символа @ используется точка.
- <serial> – порядковый номер версии файла зоны. Этот номер следует увеличивать при каждом внесении изменений в файл10.
- <refresh> – период (в секундах), с которым вторичный сервер имен обращается к основному серверу на предмет определения необходимости обновления. Разумным значением является 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.ARPA11 и C.ISI.EDU обеспечивают серверы имен для домена COM, соответствующая строка будет иметь вид:
COM. NS SRI-NIC.ARPA.
NS C.ISI.EDU.
Отметим, что машины, обеспечивающие службу имен, не находятся в указанном домене. Для каждого сервера имен в домене должна использоваться отдельная запись NS. Отметим также, что в приведенном примере для второй записи NS по умолчанию используется доменное имя COM.
Записи NS для домена существуют как в самом домене, так и зоне, которая делегирует этот домен.
Склеивающая запись
Если сервер имен для домена находится внутри этого домена, требуется использовать склеивающую (glue) запись, которая представляет собой RR типа A (адрес), указывающую адрес сервера имен. Склеивающая запись нужна только на сервере, делегирующем домен, но не в самом домене. В приведенном ниже примере для домена SRI.COM сервером имен является KL.SRI.COM. В этом случае вслед за NS-записью должна располагаться склеивающая запись A.
SRI.COM. NS KL.SRI.COM.
KL.SRI.COM. A 10.1.0.212
A (адрес)
<host> [<ttl>] [<class>] A <address>
Для записей типа A данными служит IP-адрес в десятичном формате с разделением точками. Пример записи типа 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), а во второй (software) – программ хоста. Описание оборудования обычно включает (имя производителя и модель, разделенные дефисом «-»). Вторая фраза обычно содержит название операционной системы хоста.
Официальные типы HINFO можно найти в последней версии RFC Assigned Numbers (на момент подготовки документа – RFC 101013). Тип Hardware иногда называют Machine name (имя машины), а тип Software – System name (имя системы).
Ниже приведены примеры записей HINFO.
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>
Записи WKS14 используются для перечисления общеизвестных служб, обеспечиваемых хостом. 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 Assigned Numbers (на момент подготовки документа – RFC 10102).
MX (Mail Exchanger – обмен почтой)
(см RFC 974)
<name> [<ttl>] [<class>] MX <preference> <host>
Записи 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.COM15.
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
В дополнение к этому, в трех различных зонах (одна для каждой сети) шлюз будет иметь одну из перечисленных ниже записей для указателей:
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.TXT16
- Свяжитесь с ответственным лицом родительского домена.
-
Попросите у ответственного лица отключить домен.
Примеры конфигурационных файлов для доменов
Организация домена SRI
+-------+
| COM |
+-------+
|
+-------+
| SRI |
+-------+
|
+----------++------------+
| | |
+-------+ +------+ +-------+
| CSL | | ISTC | | Хосты |
+-------+ +------+ +-------+
| |
+-------+ +-------+
| Хосты | | Хосты |
+-------+ +-------+
Ниже приведены примеры файлов зон для типичных организаций (в качестве примера такой организации используется SRI). Компания SRI решила поделить свой домен SRI.COM на несколько субдоменов (по одному для каждой пожелавшей группы). Для этих субдоменов выбраны имена CSL и ISTC.
Отметим следующие моменты:
- в домене SRI.COM присутствуют как хосты, так и субдомены;
- имя CSL.SRI.COM относится к хосту и субдомену;
- все домены обслуживаются общей парой серверов имен;
- все хосты субдомена SRI находятся в подсети 128.18, за исключением хостов субдомена CSL, относящихся к сети 192.12.3317;
-
приведенный пример не соответствует какой-либо реальной сети.
[Файл 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]
Для этого типа файлов текже отсутствует стандартизация.
;список возможных корневых серверов
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 ;порядковый номер 1800 ;обновление через 30 минут 600 ;повторная попытка через 10 минут 604800 ;устаревает через неделю 86400 ;время жизни по умолчанию 1 день18 ) SRI.COM. NS KL.SRI.COM. NS STRIPE.SRI.COM. MX 10 KL.SRI.COM. ;хосты SRI.COM 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 ;порядковый номер
1800 ;обновление через 30 минут
600 ;повторная попытка через 10 минут
604800 ;устаревает через неделю
86400 ;время жизни по умолчанию 1 день
)
CSL.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
A 192.12.33.2
;хосты CSL.SRI.COM
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 ;порядковый номер
1800 ;обновление через 30 минут
600 ;повторная попытка через 10 минут
604800 ;устаревает через неделю
86400 ;время жизни по умолчанию 1 день
)
ISTC.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 SPAM.ISTC.SRI.COM.
; хосты ISTC
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 ;порядковый номер
1800 ;обновление через 30 минут
600 ;повторная попытка через 10 минут
604800 ;устаревает через неделю
86400 ;время жизни по умолчанию 1 день
)
18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
; SRINET [128.18.0.0] преобразование адресов
; хосты SRI.COM
1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
; хосты ISTC.SRI.COM
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
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 ;порядковый номер
1800 ;обновление через 30 минут
600 ;повторная попытка через 10 минут
604800 ;устаревает через неделю
86400 ;время жизни по умолчанию 1 день
)
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] Преобразование адресов
; хосты SRI.COM
2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
; хосты CSL.SRI.COM
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 UNIX19
В этом разделе описаны для специфичных для 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).
; список возможных корневых серверов
. 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
; и их адреса
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
Приложение 120
Список корневых серверов (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.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
;
; last update: Jun 17, 2010
; related version of root zone: 2010061700
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30
;
; 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
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2F::F
;
; 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
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::803F:235
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7FE::53
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:C27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7FD::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:DC3::35
; 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-97421, CSNET CIC BBN Laboratories, January 1986.
[3] Mockapetris, P., “Domains Names – Concepts and Facilities”, RFC-103422, USC/Information Sciences Institute, November 1987.
[4] Mockapetris, P., “Domain Names – Implementations Specification”, RFC-103523, USC/Information Sciences Institute, November 1987.
Перевод на русский язык
Николай Малых
1Каждая реализация сервера имен может потребовать использования своих файлов. Файлы зон стандартизованы, но некоторые серверы могут потребовать иных стартовых файлов. Для получения нужной информации обратитесь к документации используемых вами программ. В приложении к данному документу приведен ряд конкретных примеров.
2Resource Record.
3Программа преобразования имен – resolver. Прим. перев.
4В настоящее время вы можете загрузить файл, воспользовавшись ссылкой ftp://ftp.rs.internic.net/domain/named.root. Прим. перев.
5Этот адрес на сегодняшний день также утратил актуальность и даже домен .ARPA больше не используется. Прим. перев.
6Июнь 1987. Прим. перев.
7Актуальный список корневых серверов приведен в Приложении 1. Прим. перев.
8Современный вариант определений RR содержится в RFC 1183 (русский перевод см. на сайте www.protokols.ru). Прим. перев.
9Или знаками табуляции. Прим. перев.
10Общепринятым форматом серийного номера является YYYYMMDDnn, где YYYY указывает год, MM – месяц, DD – число и nn – порядковый номер изменений за текущие сутки. Такая нумерация при аккуратном обращении с полем обеспечивает постоянное возрастание значения номера. Прим. перев.
11Домен .ARPA уже не поддерживается, поэтому нет смысла проверять реальность указанных в примерах имен. Прим. перев.
12В исходном документе после цифры 2 поставлена точка, которая является знаком препинания, а не частью записи A. Во избежание путаницы в переводе эта точка удалена. Прим. перев.
13Последняя версия документа содержится в RFC 1700, но в соответствии с RFC 3232 документ STD 2 утратил силу. Значения Assigned Numbers следует искать в базе данных, доступной на сайте www.iana.org/numbers.html. Прим. перев.
14Well Known Service – общеизвестная служба.
15Для этого хоста доставка определяется первой строкой в приведенном примере. Прим. перев.
16Сегодня информацию о доменах можно найти с помощью службы Whois на сервере http://www.networksolutions.com или серверах других регистраторов. Для росссийских доменов обращайтесь на сервер http://www.ripn.net. Прим. перев.
17Отметим, что домен не имеет соответствующей физической сети.
18В исходном документе ошибочно сказано «1 час». Прим. перев.
19 Сегодня эта программа существует для большинства клонов UNIX. Прим. перев.
20 Это приложение отсутствует в оригинальном документе и добавлено при переводе. Прим. перев.
21Этот документ признан устаревшим и заменен RFC 2821, который, в свою очередь, был заменен RFC 5321. Прим. перев.
22RFC 1101, RFC 1183, RFC 1348, RFC 1876, RFC 1982, RFC 2065, RFC 2181, RFC 2308, RFC 2535 содержат ряд дополнений и поправок к этому стандарту.Прим. перев.