РД 45.134-2000, часть 6
; hh:mm:ss zzz
dates = orig-date ; Отправлено
[ resent-date ] ; Переслано
day = "Mon" / "Tue" / "Wed" / "Thu"
/ "Fri" / "Sat" / "Sun"
delimiters = specials / linear-white-space / comment
destination = "To" ":" 1#address ; Первичный
/ "Resent-To" ":" 1#address
/ "cc" ":" 1#address ; Вторичный
/ "Resent-cc" ":" 1#address
/ "bcc" ":" #address ; Слепая пересылка
/ "Resent-bcc" ":" #address
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
domain = sub-domain *("." sub-domain)
domain-literal = "[" *(dtext / quoted-pair) "]"
domain-ref = atom ; символическая ссылка
dtext = <любой CHAR кроме "[", ; => may be folded
"]", "\" и CR, и включая
linear-white-space>
fields = dates ; Требуется Дата создания
source ; i d автора и один
1*destination ; адрес. Другие поля
*optional-field ; факультативные
group = phrase ":" [#mailbox] ";"
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
linear-white-space = 1*([CRLF] LWSP-char) ;
local-part = word *("." word) ; протоколом не интерпретируется
LWSP-char = SPACE / HTAB
mailbox = addr-spec ; простой адрес
/ phrase route-addr ; name & addr-spec
message = fields *( CRLF *text ) ; Все, что следует после
; первой пустой строки -
; это тело сообщения
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
msg-id = "<" addr-spec ">" ; Уникальный идент. сообщения
optional-field =
/ "Message-ID" ":" msg-id
/ "Resent-Message-ID" ":" msg-id
/ "In-Reply-To" ":" *(phrase / msg-id)
/ "References" ":" *(phrase / msg-id)
/ "Keywords" ":" #phrase
/ "Subject" ":" *text
/ "Comments" ":" *text
/ "Encrypted" ":" 1#2word
/ extension-field
/ user-defined-field ; может быть пустым
orig-date = "Date" ":" date-time
originator = authentic ; идентифицированный адрес
[ "Reply-To" ":" 1#address] )
phrase = 1*word
quoted-pair = "\" CHAR
quoted-string = <"> *(qtext/quoted-pair) <">;
qtext = <любой CHAR кроме <">, ; => may be folded
"\" и CR, и включая
linear-white-space>
received = "Received" ":" ; один на
["from" domain] ; оправлюящий узел
["by" domain] ; получающий узел
["via" atom] ; физический путь
*("with" atom) ; протокол соединения/почты
["id" msg-id] ; идентификатор сообщения
; получателя
["for" addr-spec] ; начальная форма
";" date-time ; время получения
resent = resent-authentic
[ "Resent-Reply-To" ":" 1#address] )
resent-authentic =
= "Resent-From" ":" mailbox
/ ( "Resent-Sender" ":" mailbox
"Resent-From" ":" 1#mailbox )
resent-date = "Resent-Date" ":" date-time
return = "Return-path" ":" route-addr ; обратный адрес
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-relative
; case-preserved
source = [ trace ] ; сетевые узлы,
originator ; переславшие сообщение
[ resent ] ;
SPACE = <ASCII SP, пробел> ; ( 40, 32.)
specials = "(" / ")" / "<" / ">" / "@" ; Для использования
/ "," / ";" / ":" / "\" / <"> ; внутри слова должен быть
/ "." / "[" / "]" ; в кавычках
sub-domain = domain-ref / domain-literal
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments и
including CRLF> ; quoted-strings
; не распознаются
time = hour zone ; ANSI и Military
; 00:00:00 - 23:59:59
trace = return ; путь к отправителю
1*received ; тэги получения
word = atom / quoted-string
zone = "UT" / "GMT" ; Время по Гринвичу
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Местное время
Приложение 4
Технические требования к техническим средствам службы доменных имен протоколу dns
1. Область применения
Настоящее приложение описывает технические требования к ТС службы доменных имен по протоколу DNS в соответствии с RFC 1034 [12] и RFC 1035 [13] .
В приложении приведены процедуры обращения клиента к распределенной базе данных доменных имен с целью получения информации, связанной с указанным доменным именем , а также описывает функционирование распределенной базы данных доменых имен.
Не все функции, содержащиеся в данном приложении, обязательны для ТС служб l доменных имен по протоколу DNS , но если они выполняются, то их реализация должна соответствовать настоящему приложению.
2. Функциональные требования к серверу DNS
2.1. Соединения
2.1.1. Протокол нижнего уровня
Сообщения DNS должны передаваться в датаграммах UDP или с использованием виртуального соединения TCP.
Контрольные файлы DNS должны передаваться с использованием протоколов надежной передачи файлов по сети передачи данных.
2.1.2. Требования к использованию протокола UDP
При использовании протокола UDP на сервере должен использоваться порт с десятичным номером 53.
При использовании UDP максимальный размер сообщения DNS должен составлять 512 байт. Более длинные сообщения должны усекаться с установкой бита TC заголовка сообщения (см. п. 4.1.2.). Протокол UDP не должен использоваться для пересылки зоны.
2.1.3. Требования к использованию протокола TCP
При использовании протокола TCP на сервере должен использоваться порт с десятичным номером 53.
При пересылке сообщений по соединению TCP сообщениям должно предшествовать поле длины размером 2 байта, содержащее значение длины сообщения без учета данного дополнительного поля.
При использовании TCP каждый семибитный символ, передаваемый по соединению TCP, должен передаваться в отдельном октете. При этом символ должен быть выровнен вправо, а старший бит октета установлен в 0.
2.1.4 . Установление соединения и закрытие соединения
При обмене сообщениями DNS в случае использования виртуального соединения соединение должно инициироваться стороной клиента.
3 . Перечень и структура данных, передаваемых по протоколу DNS
Данные должны передаваться либо в форме сообщений DNS, либо в форме контрольных файлов. Обмен данными в форме сообщений DNS должен происходить как последовательность запросов DNS и ответов DNS.
Сервер DNS должен поддерживать как клиентскую, так и серверную часть протокола DNS.
3.1. Формат сообщений DNS
3.1.1. Формат сообщений DNS должен соответствовать п. 5 .4.1.
3.1.2. Заголовок сообщения DNS должен состоять из полей: ID, QR, OPCODE, AA, TC, RD, RA, Z, RCODE, QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT.
3.1.3. Формат записей ресурсов в сообщениях DNS должен соответствовать п. 5 .3.2.
3.1.4. Должны поддерживаться следующие виды сообщений DNS:
запрос;
ответ.
3.1.5. Должен поддерживаться стандартный тип запроса. Порядок обработки запроса должен соответствовать п. 5 .4.2.1.
3.1.6. Если поддерживается инверсный тип запроса, порядок его обработки должен соответствовать п. 5 .4.2.2.
3.1.7. Должны поддерживаться следующие коды ответа:
0 - нет ошибки;
1 - ошибка формата запроса;
2 - внутренняя ошибка сервера;
3 - ошибка имени;
4 - данный вид запроса не реализован;
5 - отказ выполнения операции;
3 .1.8. Если поддерживаются рекурсивные запросы, порядок согласования выполнения рекурсивного запроса должен соответствовать п. 5.5.5., а алгоритм обработки рекурсивного запроса должен соответствовать п. 5 .5.2.
3.1.9. При выдаче сервером ответа в поле ID заголовка ответа должен содержаться идентификационный номер, совпадающий с идентификационным номером соответствующего запроса.
3.1.10. При выдаче ответа авторитетным сервером в поле AA заголовка ответа должна быть установлена 1.
3.1.11. При усечении сообщения в поле TC заголовка сообщения должна устанавливаться 1.
3.1.12. Если в сервере реализована обработка инверсных запросов, формат запроса и ответа должен соответствовать п. 5 .4.2.2.
3.2. Кодирование данных в сообщениях DNS
При сравнении любых элементов данных протокола DNS не должно делаться различия между строчными и прописными символами. Символьная форма доменного имени должна соответствовать 5 .2.1.2., а двоичная форма доменного имени должна соответствовать 5 .2.1.1.
3.3. Сжатие сообщений
Если сервер DNS поддерживает сжатие сообщений, механизм сжатия должен соответствовать п. 5 .4.3.
3.4. Контрольные файлы
В сервере должна быть реализована загрузка информации о доменном дереве из управляющего файла в формате, соответствующем п. 5 .4.4.
Должны быть исключены ситуации, когда загрузка контрольного файла осуществляется не полностью. При ошибке загрузки контрольного файла сервер имен не должен использовать информацию из данного контрольного файла.
После загрузки контрольного файла записи RR, выдаваемые в ответах сервера, должны соответствовать записям загруженного контрольного файла, если только не поступила информация об изменении зоны .
4. Требования к реализации сервера DNS
4.1. Общие требования к реализации сервера DNS
4.1.1. УТС DNS должен обеспечивать функции сервера DNS и функции клиента DNS
4.1.2. При реализации кэширования отрицательных ответов к дополнительной секции авторитетного ответа должна добавляться запись RR типа SOA. Описание типа SOA дано в п. 5.3.2.1.6.
4 .1.3. При реализации разрешающей системы и проведения поиска данных по псевдониму, должна быть выполнена цепочка запросов до получения требуемых данных, либо до выяснения ошибочного состояния. Данное требования не распространяется на запросы общего поиска.
4.1.4. Должны поддерживаться записи RR с шаблонными именами владельца согласно п. 5 .3.4.
4 .1.5. Должен поддерживаться субдомен IN-ADDR.ARPA. согласно п. 5 .2.4.
4 .2. Требования к размеру элементов протокола
Максимальный размер элементов протокола должен соответствовать табл. 1
Таблица 1
Максимальный размер элементов протокола.
-
Элементы
Максимальный размер
Labels
Метки
63 октета
Names
Имена
255 октетов
TTL
время жизни
Максимальное положительное значение 32-х битового целого со знаком
UDP messages
пакеты UDP
512 октетов
4.3. Реализация вторичного сервера зоны
4.3.1. Если сервер поддерживает функции вторичного сервера зоны DNS, временные параметры REFRESH, RETRY, EXPIRE процедуры отслеживания изменений зоны на первичном сервере должны соответствовать значениям, установленным в записи RR SOA для данной зоны.
4.3.2. Получение измененной зоны должно выполняться при помощи запроса AXFR. Команда AXFR должна выдаваться первичному серверу при обнаружении увеличения параметра SERIAL записи RR SOA для данной зоны на первичном сервере.
4.4. Реализация первичного сервера зоны
Если сервер поддерживает функции первичного сервера зоны DNS, при получении запроса AXFR он должен выдать ответы, содержащие все записи RR, относящиеся к зоне, указанной в запросе. Причем первое и последнее сообщения ответа должны содержать данные для верхнего авторитетного узла в зоне.
5.ОПИСАНИЕ СИСТЕМЫ ДОМЕННЫХ ИМЕН
5.1. Структура системы доменных имен
5.1.1. Основные компоненты системы доменных имен.
В DNS входят три основные компоненты:
- пространство доменных имен. Каждый узел и лист древовидного пространства доменных имен указывает на некоторый набор данных. Операции выполнения запроса можно рассматривать как попытку выделить определенные типы данных из отдельного набора.
- серверы имен . Сервером имен называется серверное программное обеспечение, хранящее информацию о структуре доменного дерева и соответствующие наборы данных. Сервер имен может кэшировать структуру и данные любой части доменного дерева, но, как правило, отдельный сервер имен содержит полную информацию о каком-либо подмножестве доменного пространства и указатели на другие серверы имен, с помощью которых можно найти информацию о любой части доменного дерева. Если сервер обладает полной информацией о какой-либо части доменного дерева (о зоне доменного дерева), его называют авторитетным сервером (AUTHOR IT Y) данной зоны, а информацию об этой зоне, хранимую на данном сервере - авторитетной информацией.
разрешающая система . Разрешающая система обеспечивает доступ к распределенной базе данных доменных имен, расположенной на множестве серверов имен. Разрешающая система позволяет продолжить запрос клиента в случае отсутствия на конкретном сервере запрашиваемой информации.
С точки зрения клиента доменное пространство состоит из одного дерева, причем доступна любая его часть. С точки зрения разрешающей системы доменная система состоит из неизвестного количества серверов имен. С точки зрения сервера имен доменная система состоит из отдельных наборов локальной информации, называемых зонами. Сервер должен одновременно обслуживать запросы от нескольких разрешающих систем.
Предполагается, что в доменной системе все данные находятся в контрольных файлах (master files), распределенных по узлам сети, использующим доменную систему. Изменения в данные контрольных файлов заносятся системными администраторами. Контрольные файлы имеют стандартный текстовый формат, поэтому различные узлы могут обмениваться контрольными файлами с использованием любых средств передачи файлов.
Серверы имен являются хранилищем информации, составляющей распределенную базу данных имен домена. База данных разделена на секции, называемые зонами. Зоны распределены между серверами имен. Для повышения надежности, одна зона должна содержаться на нескольких серверах имен. Один сервер имен обычно поддерживает одну или несколько зон. Он имеет авторитетную информацию о достаточно небольшом участке пространства имен и также может иметь неавторитетную кэшированную информацию о некоторых других частях дерева. Кэшированная информация используется местной разрешающей системой. Сервер имен помечает ответы таким образом, чтобы запросчик мог различать авторитетные данные от неавторитетных. Периодически сервер имен делает проверку актуальности хранимых им данных, и, в случае, если хранимые данные не актуальны, сервер получает копию обновленной зоны из контрольных файлов, хранящихся локально или на другом сервере имен.
5.1.2. Основные конфигурации взаимодействия сервера, клиента и разрешающей системы в системе DNS.
Клиентом называется процесс, использующий функции системы доменных имен. Сервером имен называется процесс, выполняющий совместно с процессом клиента функции доступа к системе доменных имен. Внешний сервер имен - сервер имен, который взаимодействует с клиентом через разрешающую систему другого сервера.
Как правило клиент выполняет функции либо часть функций разрешающей системы, что дает ему потенциальную возможность доступа к системе доменных имен путем обращений к нерекурсивным серверам имен. Клиент, у которого не реализованы функции разрешающей системы, при взаимодействии с нерекурсивным сервером имен будет иметь возможность доступа только к той части доменного пространства, которая хранится на данном сервере имен.
Рисунок. 1. Доступ клиента к пространству доменных имен через рекурсивный сервер имен
Рисунок. 2. Доступ клиента к пространству доменных имен через нерекурсивный сервер имен
5.2. Структура пространства доменных имен
Пространство доменных имен является древовидной структурой. Каждый узел и лист дерева соответствует определенному набору данных о ресурсах. Этот набор данных может быть пустым. Доменная система одинаково использует внутренние узлы и листья дерева, поэтому далее листья называются тоже узлами дерева. Каждому узлу дерева присвоена метка длиной от 0 до 63 символов. Длина метки корневого узла должна быть равна 0.
Имя домена состоит из меток, находящихся на пути от данного узла к корню доменного дерева и идентифицирует узел доменного дерева. Набор данных о ресурсе, связанный с отдельным доменным именем, содержится в одной или более записях ресурса (RR). Порядок следования RR в наборе для одного доменного имени является несущественным.
Домен A называют субдоменом другого домена B, если A содержится в домене B.
Кроме разделения на субдомены рассматривают разделение доменов на классы и зоны. Разделение домена на классы осуществляется в соответствии со значением поля CLASS записей RR, в которых хранится информация о домене. Разделение на зоны рассматривается в п. 6.2.3.
Замечание: Необходимо различать понятия "узел доменного дерева" и "узел сети передачи данных". Узел сети передачи данных может иметь несколько сетевых адресов, которым будут соответствовать несколько узлов доменного дерева. Узел сети передачи данных может вообще не иметь доменного имени и соответствующего узла доменного дерева.
5.2.1. Доменные имена
Доменное имя узла - это список меток, находящихся на пути от данного узла к корню доменного дерева. Метки, составляющие доменное имя, должны располагаться слева направо, от метки, наиболее удаленной от корня, к метке, наиболее близкой к корню.
При хранении доменных имен запоминается регистр символов, но при любых сравнениях меток регистр не учитывается. Доменное имя может быть представлено в двух формах: в символьной форме и в двоичной форме.
5.2.1.1. Внутренняя форма представления доменного имени
Каждая метка хранится в виде одного октета длины, за которым следует некоторое количество октетов, содержащих символы метки. Так как каждое доменное имя заканчивается нулевой меткой, обозначающей корень, представление каждого доменного имени заканчивается октетом длины, содержащим 0. Октет длины содержит два старших бита, установленных в 0. Оставшиеся 6 битов содержат значение длины поля символов метки от 0 до 63. Общая длина доменного имени (сумма всех октетов символов и октетов длин) не должна превышать 255 октетов.
Внутренняя форма представления доменного имени должна соответствовать следующему определению:
Все символы должны быть закодированы в ASCII
domain-name ::= [ subdomain ] nul-label
subdomain ::= label / (subdomain label)
label ::= length letter [ [ ldh-str ] let-dig ] ; максимальная длина label
; составляет 63 символа
length ::= 2(0bit) len-val
len-val ::= 6(Xbit) ; 6-битное значение длины соответствующей
; метки label
nul-label ::= 8(0bit)
character-string ::= s_length *256(char) ; символьная строка
s_length ::= 8(Xbit) ; длина символьной строки в
; октетах
ldh-str ::= let-dig-hyp / (let-dig-hyp ldh-str)
let-dig-hyp ::= let-dig / "-"
let-dig ::= letter / digit
letter ::= <любая из 52 алфавитных символов кода ASCII
от A до Z и от a до z>
char ::= <любой символ кода ASCII>
digit ::= <любая из 10 цифр от 0 до 9>
Xbit ::= <бит>
0bit ::= <бит, установленный в 0>
unsigned_int32 ::= 32(Xbit) ; 32-разрядное целое без знака
5.2.1.2. Печатная форма представления доменного имени
В печатной форме доменные имена представляются как список меток, разделенных одной точкой.
Все символы должны кодироваться в ASCII.
domain ::= subdomain / " "
subdomain ::= label / (subdomain "." label)
label ::= letter [ [ ldh-str ] let-dig ] ; максимальная длина label
; составляет 63 символа
ldh-str ::= let-dig-hyp / (let-dig-hyp ldh-str)
let-dig-hyp ::= let-dig / "-"
let-dig ::= letter / digit
letter ::= <любая из 52 алфавитных символов кода ASCII
от A до Z и от a до z>
digit ::= <любая из 10 цифр от 0 до 9>
В печатной форме различают полное доменное имя, имеющее точку на правом конце и неполное (относительное) доменное имя без точки на правом конце. Неполные имена используются относительно хорошо известного источника, либо относительно списка доменов, используемых в качестве поискового списка.
5.2.2. Псевдонимы и канонические имена
Узлы и другие ресурсы часто имеют несколько имен. Как правило одно из набора эквивалентных имен называют каноническим или первичным, а остальные - псевдонимами.
Псевдоним присваивается узлу с помощью соответствующей записи RR типа CNAME. Запись RR типа CNAME содержит в разделе " владелец" псевдоним владельца, а в разделе RDATA - соответствующее каноническое имя. Если в узле присутствует RR типа CNAME, то не должно быть никаких других данных для этого узла.
Когда сервер имен не может найти желаемый RR в наборе, связанном с доменным именем, сервер проверяет, нет ли в наборе RR записей типа CNAME соответствующего класса. Если есть, сервер имен включает запись RR CNAME в ответ и возобновляет запрос к доменному имени, указанному в поле RDATA записи CNAME. Запросы, соответствующие типу CNAME, не возобновляются.
Если в RR типа CNAME вместо канонического имени указан псевдоним, сервер DNS должен проследить всю цепочку таких RR, пока не будет найдено каноническое имя, либо не будет выявлена ошибка.
5.2.3. Зоны домена
5.2.3.1. Разбиение домена на зоны
Внутри класса домена могут быть сделаны "разрезы" между двумя любыми смежными узлами. После того, как это сделано, каждая отдельная группа не разделенных разрезами узлов образует одну зону. Считается, что зона авторитетна для всех узлов в связанной области. Для разных классов "разрезы" могут быть произведены в разных местах.
Таким образом каждая зона имеет как минимум один узел и, следовательно, как минимум одно доменное имя, для которого данная зона авторитетна. В древовидной структуре домена каждая зона имеет один верхний узел, расположенный наиболее близко к корню дерева по сравнению с другими узлами зоны. Имя этого верхнего узла часто используется для обозначения зоны.
Данные, описывающие зону, могут быть разделены на четыре части:
- Авторитетные данные для всех узлов данной зоны
- Данные, определяющие верхний узел зоны
- Данные, описывающие делегированные подзоны
- Данные, позволяющие получить доступ к доменным именам подзон (так называемые "клеевые" записи).
Все эти данные представлены в виде записей RR. Таким образом зона может быть полностью описана набором RR. Зона может быть перенесена с одного сервера имен на другой путем передачи записей RR либо путем передачи целого контрольного файла.
Записи RR, описывающие верхний узел зоны, разделяются на: записи NR RR, представляющие список всех серверов имен данной зоны, и одну запись SOA RR, описывающую параметры управления зоной.
Записи RR, описывающие "разрезы" на "дне" зоны (определяющие подзоны), обозначаются NS RR и указывают на сервер имен подзоны.
Данные NS RR не являются частью авторитетных данных зоны, так как определяют "разрезы" между узлами, а не узлы (так как не содержат адресной информации). Каждая запись NS RR должна быть идентична верхней записи RR соответствующей подзоны. В отдельной зоне записи NS RR должны располагаться рядом с верхним узлом зоны (они входят в число авторитетных) или на " разрезах" вокруг " дна" зоны (они не входят в число авторитетных), но никогда не должны располагаться посредине зоны.
Так как записи NS RR содержат только имена серверов подзон, но не содержат адресов серверов подзон, зона содержит "клеевые" записи RR (не являющиеся авторитетными), которые являются адресными RR для данных серверов. "Клеевые" RR используются в ссылочном ответе.
5.2.3.2. Распространение изменений зоны
Для распространения изменений зоны может использоваться любая процедура передачи контрольного файла, но предпочтительным методом является использование сообщений протокола DNS.
В основной модели автоматической пересылки и обновления зоны один из серверов назначается первичным для данной зоны. Изменения производятся на первичном сервере (обычно путем исправления контрольного файла зоны). После исправления администратор дает первичному серверу загрузить новую зону. Вторичные серверы зоны периодически проверяют наличие изменений и получают новые копии зоны в случае, если сделаны изменения.
Для проверки наличия изменений вторичные серверы проверяют поле SERIAL записи SOA данной зоны. Если в зоне производятся какие-либо изменения, значение поля SERIAL всегда увеличивается. Механизм изменения может быть либо простым увеличением значения, либо может использовать текущую дату.
Параметры периодической переклички вторичных серверов устанавливаются в SOA RR данной зоны. Этими параметрами являются: REFRESH, RETRY и EXPIRE. Когда вторичный сервер загружает новую зону, он ждет REFRESH секунд перед новой проверкой поля SERIAL. Если не обнаружено изменений (значение поля SERIAL - прежнее), вторичный сервер опять ждет REFRESH секунд. В случае, если проверка не может быть произведена, сервер ждет RETRY секунд до повторной проверки. Если вторичному серверу не удалось провести проверку в течение EXPIRE секунд, он должен считать копию зоны устаревшей и уничтожить ее.
Это значит, что в случаях ошибки чтения зоны или в случае просрочки обновления зоны, сервер имен должен выдавать ответы на запросы таким образом, как если бы он вообще не владел этой зоной. Во время пересылки новых данных о зоне сервер имен должен выдавать старые данные, пока пересылка не будет полностью закончена.
Если вторичный сервер обнаружил, что на первичном сервере зона изменена, сервер должен запросить командой AXFR передачу зоны. Первое и последнее сообщения, передаваемые в ответ на команду, должны содержать данные для верхнего авторитетного узла в зоне. Промежуточные сообщения должны содержать остальные RR зоны, как авторитетные, так и неавторитетные. Команда AXFR должна использовать протокол TCP.
Данный механизм копирования зон может применяться вторичными серверами не только к первичным серверам, но и к другим вторичным серверам.
5.2.4. Домен IN-ADDR.ARPA
Internet использует специальный субдомен для поддержки трансляции адресов узлов. Назначение этого субдомена - предоставлять надежный метод трансляции адресов узлов в имена узлов, а также поддерживать запросы по установлению местонахождения всех шлюзов в отдельной сети в Internet.
Обе указанные функции аналогичны функциям, выполняемым инверсными запросами. Отличие заключается в том, что эта часть доменного имени структурирована согласно адресу, то есть гарантируется, что соответствующие данные могут быть найдены без выполнения поиска в доменном пространстве.
Субдомен начинается с метки IN-ADDR.ARPA и имеет подструктуру, соответствующую структуре адресации Internet. Доменные имена могут иметь до 4-х меток в дополнение к IN-ADDR.ARPA. Каждая метка представляет собой один октет адреса IP в формате десятичного целого от 0 до 255 ( с опущенными лидирующими нулями). Адрес узла соответствует имени, в котором присутствуют все 4 метки. Например, узел с адресом 10.2.0.52 будет иметь имя 52.0.2.10.IN-ADDR.ARPA.
Имена с количеством меток менее 4-х соответствуют зоне, выделенной для отдельной сети.
Сетевые номера соответствуют некоторым неконечным узлам, располагающимся на различной глубине домена IN-ADDR.ARPA. Сетевые узлы используются для хранения указателей на первичные узловые имена шлюзов, присоединенных к данной сети. Так как шлюз находится более чем в одной сети, имеются два или более сетевых узлов, указывающих на него. Шлюзы также имеют указатели уровня узла на их полные адреса.
Шлюзовые указатели на сетевые узлы и обычные узловые указатели на полные сетевые адреса используют PTR RR для обратной ссылки на первичные доменные имена соответствующих узлов.
Пример:
Домен IN-ADDR.ARPA содержит информацию:
о шлюзе MILNET-GW.ISI.EDU между сетями 10 и 26 с адресами 10.2.0.22 и 26.0.0.103
о шлюзе GW.LCS.MIT.EDU между сетями 10 и 18 с адресами 10.0.0.77 и 18.10.0.4
об узле A.ISI.EDU
об узле MULTICS.MIT.EDU
База данных домена будет содержать:
10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.