В этом материале мы рассмотрим, как решается в DNS задача поиска доменного имени по IP-адресу, что из себя представляет загадочный домен IN-ADDR.ARPA, какие проблемы возникают при делегировании "обратных" зон.

Задача поиска доменного имени по IP-адресу является обратной к прямой задаче - поиску IP-адреса по доменному имени. Как было рассмотрено в материале "Адресная запись "Address"…" прямая задача решается в DNS при помощи записей типа A (Address). Обратная же задача решается при помощи записей-указателей типа PTR (Pointer), которые совместно с записями SOA и NS составляют описание так называемой "обратной" зоны.

На самом деле в DNS решение задачи поиска доменного имени по IP-адресу несколько необычно. Казалось бы, что для решения этой задачи можно использовать описание "прямой" зоны. В ней ведь вся информация есть!

На самом деле решать "обратную" задачу по "прямой" зоне неудобно. Поиск сведется к полному перебору всех зон, т.к. удобного аппарата рефералов (отсылок по NS записям) для IP-адресов в прямых зонах нет.

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

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

Вот здесь и возникает довольно логичное и простое решение, которое позволяет использовать стандартный механизм поиска доменного имени для решения "обратной" задачи, - специальный домен, структура которого совпадает со структурой IP-адресов. Называется этот домен IN-ADDR.ARPA.

Сначала немного истории. В то время когда затевалась система доменных имен (примерно 1983 год - год выхода RFC 882 и 883) под Internet подразумевалась сеть ARPA, а кроме нее еще обсуждалась возможность построения единого адресного пространства с CSNET. По этой причине кроме класса записей описания ресурсов IN - INTERNET (в то время ARPA) был еще класс описания ресурсов CS - CSNET (Computer Science Network).

В рамках этой концепции в сети ARPA вводился домен для адресов интернет (IN-ADDR - Internet ADDRess). При этом отдельно оговаривалось, что для других сетей алгоритм поиска доменного имени по IP-адресу может отличаться от того, который предложен для адресного пространства сети ARPA.

При этом доменные адреса в ARPA оканчивались словом "ARPA", вот пример из RFC 883:

.. 9999999 IN NS B.ISI.ARPA
9999999 CS NS UDEL.CSNET
B.ISI.ARPA 9999999 IN A 10.3.0.52
UDEL.CSNET 9999999 CS A 302-555-0000

В нем мы видим, что у записей класса IN доменное имя оканчивается на ARPA, а у всех записей класса CS - на CSNET. Таким образом домен IN-ADDR был доменном верхнего уровня в рамках Internet (ARPA) в то время.

Сейчас уже нет ни CSNET, ни более поздних CH (CHAOS) и HS(Hesiod), которые можно найти в спецификации RFC 1035. Была реорганизована и исчезла ARPA. Но задуманный для адресного пространства ARPA домен IN-ADDR.ARPA остался.

На самом деле, в апреле 2000 года между DARPA (бывшей ARPA) и ICAAN было заключено соглашение о том, что домен верхнего уровня (TLD) ARPA будет использоваться для целей поддержки инфраструктуры Интернет.

Кроме того, само слово "ARPA" следует расшифровывать как "Address and Routing Parameter Area Domain (ARPA)", и не следует его ассоциировать с сетью ARPANET.

Основное назначение домена ARPA - обеспечивать отображение численных величин, определяемых протоколами межсетевого обмена, в пространство имен.

Делегирование поддоменов в домене ARPA возложено на IAB (Internet Architecture Board). В настоящее время в ARPA выделено три поддомена:

• in-addr.arpa для отображения IP-адресов IPv4 в пространство доменных имен;
• ip6.arpa для отображения IP-адресов IPv6 в пространство доменных имен;
• е164.arpa для отображения телефонных номеров формата Е.164.

Сама зона ARPA поддерживается корневыми серверами и серверами TLD зон, хотя в соответствии с рекомендациями RFC 2870 для ARPA желательно выделение отдельных серверов.

Имена в домене IN-ADDR.ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, машина vega-gw.vega.ru, которая имеет адрес 194.226.43.1 должна быть описана в домене in-addr.arpa как 1.43.226.194.in-addr.arpa, т.е. адрес записывается в обратном порядке.

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

Рис.1. Пример структуры части домена in-addr.arpa

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

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

Однако на самом деле сама идея инверсной записи IP-адреса опирается на принципы построения этого адреса. Понятно, что первая группа цифр, ближайших к корню IN-ADDR.ARPA, задает номер сети, а остальные номер хоста. Принимая во внимание тот факт, что первоначально при создании доменной адресации в ARPA речь шла о сетях класса A (первый байт-октет определяет номер сети), то первая цифра в доменном имени в зоне IN-ADDR.ARPA - это номер сети, а все последующие - это номер хоста:

1.0.0.10.IN-ADDR.ARPA

Пример определяет первый хост в 10-ой сети.

Поиск этого адреса занял бы поиск сервера, ответственного за 10.IN-ADDR.ARPA, а тот бы ответил именем соответствующим адресу хоста.

В настоящее время, когда адреса раздаются, главным образом, из сетей класса C, и сама классификация сетей подменена спецификацией CIDR, цепочка обращений к серверам доменных имен значительно длиннее, но тем не менее, работает она также исправно, как и вся система DNS.

Теперь, прежде чем обсуждать проблемы поиска доменных имен в IN-ADDR.ARPA, необходимо вернуться к формату описания зон этого домена, которые принято называть "обратными".

Обратная зона состоит, главным образом из записей типа "Pointer" или PTR-записей. Формат записи имеет следующий вид:

[name][ttl] IN PTR [host]

Поле имя задает номер. Это, как уже обсуждалось, не реальный IP-адрес машины, а имя в специальном домене in-addr.arpa или в одной из его зон.Приведем пример PTR записи:

$ORIGIN 43.226.194.in-addr.arpa.
1 IN PTR vega-gw.vega.ru.

По всей видимости провайдер выделили организации сетку класса С 194.226.43.0 (В нотации CIDR 194.226.43.0/24). При этом организации было также делегировано право ведения "обратной" зоны 43.226.194.in-addr.arpa. Вот в этой зоне администратор зоны и начал описывать "обратные" соответствия.

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

В качестве примера для нашей учебной зоны в файле named.boot (BIND 4 или named.conf для BIND 8 - 9) определена "обратная" зона 43.226.194.in-addr.arpa. Ее описание будет выглядеть примерно так:

$TTL 3600
@ IN SOA vega-gw.vega.ru hostmaster.vega.ru (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
3600 ) ; negative caching
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
;
1 IN PTR vega-gw.vega.ru.
4 IN PTR dos1.vega.ru.
5 IN PTR dos2.vega.ru
2 IN PTR zone1-gw.zone1.vega.ru.
3 IN PTR zone2-gw.zone2.vega.ru.

Из этого примера видно, что для обратной зоны указаны те же записи описания зоны, что и для "прямой". Кроме того, обратную зону вовсе не обязательно разбивать в соответствии с разделением прямой зоны на другие зоны. Речь в данном случае идет о зонах zone1 и zone2. С точки зрения домена in-addr.apra все машины принадлежат одной зоне - 43.226.194.in-addr.arpa.

Другое дело машина с IP-адресом 127.0.0.1 (localhost). С точки зрения домена in-addr.arpa она принадлежит другой ветке иерархии, отличной от той, которой принадлежат все остальные хосты. Поэтому для домена 127.in-addr.arpa на любой машине есть отдельный файл обратной зоны, хотя localhost, которому соответствует этот IP-адрес, обычно описывается в прямой зоне домена вместе с другими хостами. Вот пример описания этой зоны:

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10
; 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
$TTL 3600
@ IN SOA generate.polyn.kiae.su. root.generate.polyn.kiae.su. (
00000001 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS generate.polyn.kiae.su.
1 IN PTR localhost.polyn.kiae.su.
>

Как следует из комментария этого файла для его генерации можно использовать специальный sh-скрипт make-localhost, который входит в комплект поставки BIND. Он берет в качестве основы файл прототипа PROTO.localhost.rev подставляет в него имя хоста и имя домена.

Любопытно, что вместо пользователя hostmaster, что рекомендовано в RFC2142, в данном случае указывается пользователь root. Оно и понятно. Пользователя hostmaster может и не быть, ведь не все читают все подряд RFC, а пользователь root есть обязательно. Тем более, что это скорее всего и есть администратор локального сервера доменных имен.

Следует при этом помнить, что в файле конфигурации named.conf должен быть блок, который указывает на эту "обратную" зону:

zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};

На самом деле мы опустили один интересный вопрос, а как прямой IP-адрес формата IPv4 преобразуется в доменное имя, которое имеет инверсную запись цифр.

Эти функции возложены на resolver. Resolver преобразует 32-битовый адрес в текстовую строку, размещая октеты в обратном порядке, разделяя их символами ".". К полученному имени resolver через разделитель "." добавляет суфикс "in-addr.arpa". После этого формирует PTR запрос к системе доменных имен.

Вопросы делегирования зон в IN-ADDR.ARPA не столь просты, как может показаться на первый взгляд. Эта проблема тесно связана с получением пулов IP-адресов. Кроме получения адреса, нужно еще получить право на ведение обратного домена, соответствующего вашему адресному пулу.

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

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

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

Прежде всего, следует знать, что первоначально все адреса, которые мы используем в RuNet, получают RIPE Network Coordination Centre (RIPE - это Reseaux IP Europeens), который является одним из трех региональных интернет регистраторов поддерживающих глобальную инфраструктуру Интернет.

Из предыдущего абзаца важно только то, что все блоки адресов в нотации CIDR xxxx.xxxx.xxxx.xxxx/16 и xxxx.xxxx.xxxx.xxxx/24 выдаются этой организацией локальным интернет регистраторам (Local Internet Registres - LIR). А вот уж они и распределяют эти адреса между своими клиентами.

В обычной классификации сетей Интернет это означает, что RIPE NCC отвечает за делегирование в зоне IN-ADDR.ARPA не только сетей класса B, но и сетей класса C. Сети класса B сейчас почти не выдают, поэтому смело можно остановиться на сетях класса C.

Если Вы не являетесь LIR, а Вам выделена сетка класса C, то направить заявку на делегирование обратной зоны в RIPE NCC Вы напрямую все равно не сможете. Сделать это сможет только провайдер, имеющий статус LIR, который, собственно, эту сетку в RIPE NCC получил. Следовательно, нужно связываться с ним и выяснять все вопросы делегирования обратной зоны. Если Вам выделен пул адресов из сетки класса B, то все вопросы по делегированию обратной зоны нужно также направлять своему провайдеру, т.к. именно ему делегировано право управления обратной зоны этой сети.

Если Вы сами имеете статус LIR, то лучше всего не читать это краткое описание, а обратиться к первоисточникам (http://www.ripe.net/ripencc/mem-services/rigistration/reverse/howtoreverse.html или http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt)J.

Тем не менее следует знать, что для делегирования зоны необходимо три вещи:

1. получить адресный блок;
2. обеспечить поддержку зоны /16 или /24 в соответствии с требованиями RIPE NCC;
3. направить заявку в RIPE NCC на делегирование домена.

Адресный блок получают в соответствии с документом RIPE "IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region".

Требования по поддержке зоны заключаются в том, что параметры записи SOA зоны должны соответствовать RFC 1912. при этом серийный номер зоны следует записывать в виде YYYYMMDDnn.

Для зон /24 LIR должен организовать два сервера (один у себя, а другой желательно у другого провайдера, во всяком случае, должно быть обеспечено независимое подключение). Для зон /16 должно быть обеспечено 3 сервера, причем один из них дожен быть сервер RIPE NCC ns.ripe.net. Он должен выполнять функцию slave (secondary) для зоны.

Заявка на делегирование зоны, которая посылается в RIPE NCC роботу регистрации на адрес Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. , должна выглядеть примерно так:

domain: 65.35.80.in-addr.arpa
descr: Reverse delegation for Bluelight 2nd /24
admin-c: JJ231-RIPE
tech-c: JAJA1-RIPE
zone-c: WF2121-RIPE
nserver: ns.bluelight.nl
nserver: ns2.bluelight.nl
mnt-by: BLUELIGHT-MNT
changed: Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. 19991110
source: RIPE

О назначении полей и правилах их заполнения лучше всего справиться у вашего LIR, либо в nic.ru, либо в RIPE.

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

Отдельно обратим внимание на то, что для каждой "обратной" зоны, которая соответствует сети класса C (адреса в CIDR xxxx.xxxx.xxxx/24) нужно свое собственное описание зоны. Нельзя в один файл мешать несколько зон данного типа. Мешать их может только в файле, описывающем родительскую зону типа xxxx.xxxx/16, например, в зоне 206.144.in-addr.arpa могут быть записи типа PTR для зон 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa, и то, только при условии, что данные зоны не делегированы на другой сервер.

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

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

Но на самом деле для небольших компаний гораздо более серьезной проблемой становится делегирование обратных зон для пулов адресов, меньших, чем сеть класса С. Рассмотрим эту проблему более подробно. Все примеры будем брать из RFC 2317, т.к. именно оно рекомендовано RIPE NCC для решения нашей проблемы. Именно этот способ поддерживается в самом RIPE NCC.

Сначала о существе проблемы. Провайдер "нашинковал" в сети класса С (пул адресов в нотации CIDR /24) на несколько частей. Таким образом границы пулов адресов не приходятся на границы октетов.

Пусть мы имеем дело с сетью 192.0.2.0/24. Провайдер разделил адресное пространство следующим образом:

192.0.0/25 - организация А
192.0.128/26 - организация Б
192.0.192/26 - организация С

Классическое описание обратной зоны может выглядеть примерно так:

$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.a.ru.
2 PTR host2.a.ru.
3 PTR host3.a.ru.
;
129 PTR host1.b.ru.
130 PTR host2.b.ru.
131 PTR host3.b.ru.
;
193 PTR host1.c.ru.
194 PTR host2.c.ru.
195 PTR host3.c.ru.

Делегировать поддержку такой зоны можно только кому-то одному. Все остальные будут зависимы от владельца зоны и все изменения должны будут вносить через него.

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

$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns.provider.ru. hostmaster.provider.ru. (…)
;
; 0-127 /25
;
0/25 IN NS ns.a.ru.
0/25 IN NS ns.slave.ru.
;
1 IN CNAME 1.0/25.2.0.192.in-addr.arpa.
2 IN CNAME 2.0/25.2.0.192.in-addr.arpa.
3 IN CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; 129-191 /26
;
128/26 IN NS ns.b.ru.
128/26 IN NS ns.slave.ru.
;
129 IN CNAME 129.128/26.2.0.192.in-addr.arpa.
130 IN CNAME 130.128/26.2.0.192.in-addr.arpa.
131 IN CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; 193-255 /26
;
192/26 IN NS ns.c.ru.
192/26 IN NS ns.slave.ru.
;
193 IN CNAME 193.192/26.2.0.192.in-addr.arpa.
194 IN CNAME 194.192/26.2.0.192.in-addr.arpa.
195 IN CNAME 195.192/26.2.0.192.in-addr.arpa.

Сами организации при это обязаны зависти зоны следующего содержания:

$ORIGIN 0/25.2.0.192.in-addr.arpa.
@ IN SOA ns.a.ru hostmaster.a.ru (…)
IN NS ns.a.ru.
IN NS ns.slave.ru.
;
1 IN PTR host1.a.ru.
2 IN PTR host2.a.ru.
3 IN PTR host3.a.ru.

Для блока 128/26 соответственно последовательность "0/25" следует заменить на "128/26", а сервер ns.a.ru на сервер ns.b.ru. Для блока 192/26 нужно также будет выполнить соответствующие замены.

Идея данного метода заключается в том, что, попадая в зону 2.0.192.in-addr.arpa, локальный сервер доменных имен или resolver на свой запрос доменного имени получают CNAME, т.е. сервер зоны говорит, что имя, которое ему было сообщено не является каноническим именем хоста, указанным в адресной записи. Это лишь синонимом канонического имени. При этом каноническое имя сообщается в качестве ответа на запрос. Обращаясь по каноническому имени, локальный сервер доменных имен или resolver получают в ответ ссылку на другой сервер, т.к. в нашей зоне указан NS для поддержки зон с каноническими именами. Переходя на новый сервер, локальный сервер доменных имен или resolver получают уже обычную PTR запись ресурсов и могут сообщить доменное имя приложению, которое инициировало запрос к обратной зоне.

Может показаться накладным набивать большое количество CNAME в зонах типа 2.0.192.in-addr.arpa. Но здесь можно воспользоваться директивой управления $GENERATE, которая существенно сократит число набираемых вручную записей описания ресурсов.

Следует также обратить внимание на то, что имена зон в 2.0.192.in-addr.arpa могут быть любыми допустимыми именами, а не только "0/25" или "192/26", как это указано в примере. Более того, имена могут указывать на зоны из совершенно других доменов, не входящих в in-addr.arpa. Правда, зоны должны содержать соответствующие PTR записи описания ресурсов.

Мы в самом начале этого материала упоминали об инверсных запросах, которые не следует путать со стандартными запросами к серверам домена IN-ADDR.ARPA. Какова их судьба?

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

При этом реальная область применения такого сорта запросов ограничивается рамками одного сервера.

И в заключении о том, зачем вообще нужно искать доменные имена по IP_адресам. Этому есть несколько причин.

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

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

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

Любопытно, что на 1999 год по данным RIPE NCC из 163124 зон, которые могли бы быть делегированы (зарегистрированые IP-адреса), реально было делегировано только 85352 или примерно 52%.

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

Рекомендованная литература:

1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. H.Eidnes, G. de Groot, P. Vixie. RFC-2317. Classless IN-ADDR.ARPA delegation. 1998. (http://www.ietf.org/rfc/rfc2317.txt?number=2317)
4. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
5. Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)

Полезные ссылки:

1. P. Mockapetris. RFC-883. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc883.txt?number=883) - документ интересен с точки зрения исторического развития домена IN-ADDR.ARPA как домена "обратного" соответствия.
2. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. RFC 2870. Root Name Server Operational Requirements. 2000. (http://www.ietf.org/rfc/rfc2870.txt?number=2870)
3. D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997. (http://www.ietf.org/rfc/rfc2142.txt?number=2142)
4. D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912)
5. Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region (http://www.ripe.net/ripe/docs/ripe-224.html) - очень коротенькое описание политики делегирования обратных зон в зоне ответственности RIPE NCC.
6. Reverse Delegation. IPv4 Request Procedure (reverse /24, /16) (http://www.ripe.net/ripencc/mem-services/registration/reverse/howtoreverse.html) - документ в стиле "делай раз, делай два, …". Все просто и доступно, но нужно иметь некоторое представление об устройстве сервисов RIPE NCC.
7. http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt - материалы учебного курса для LIR, которые зарегистрированы в RIPE. Интересен раздел 9 - "Reverse Delegation". Достаточно сжато и подробно описывается процедура делегирования "обратных" зон из зоны ответственности RIPE NCC.
8. G.Huston. RFC-3172. Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). 2001. (http://www.ietf.org/rfc/rfc3172.txt?number=3172) - статус домена ARPA, начиная с конца апреля 2000 года. Документ фиксирует состояние домена ARPA, ответственность ICAAN и IAB за управление этим доменом, его статус, а также правила делегирования поддоменов.
9. http://www.ripe.net/ripencc/pub-services/stats/revdns/assign/19990426.html - статистика соответствия регистрации пулов адресов и "обратных" зон на 1999 год в RIPE NCC.