RMNT.RU / Нормативные документы / СанПиНы, руководящие документы / РД

РД 45.134-2000, часть 7

103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.

6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

Программа, желающая найти шлюз в сеть 10, выдаст запрос со значениями: QTYPE=PTR, QCLASS=IN, QNAME =10.IN-ADDR.ARPA.

и получит ответ с записями RR:

10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.

10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.

Разрешающая система, желающая найти имя узла с адресом 10.0.0.6 выдаст запрос со значениями: QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA

и получит в ответ:

6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

Замечание: если узел имеет два имени в различных доменах, только одно из этих имен может быть каноническим.

5.3. Записи ресурсов

Имя домена идентифицирует узел доменного дерева. В каждом узле имеется набор связанной информации о ресурсе. Этот набор может быть пустым. Набор информации о ресурсе, связанный с отдельным доменным именем содержится в одной или нескольких записях ресурса (RR). Порядок RR в наборе, относящемуся к одному доменному имени, является несущественным.

5.3.1. Общая структура записи ресурса RR

В отдельную запись ресурса RR входят разделы, приведенные в табл. 2.

Таблица 2

Разделы отдельной записи ресурса RR

Имя элемента		Описание
Владелец	owner	доменное имя, в котором находится RR
Тип	type	16-битное значение, определяющее тип ресурса: A - адрес узла CNAME - каноническое имя HINFO - процессор или ОС, используемые узлом MX - почтовый шлюз домена NS - авторитетный сервер имен домена PTR - указатель на другую часть пространства доменных имен SOA - начало авторитетной зоны
Класс	class	16-битное значение, определяющее семейство или отдельный протокол: IN - система Internet CH - система Chaos
Время жизни	TTL
Данные ресурса	RDATA	Данные, описывающие ресурс и зависящие от типа и класса записи: A - для IN 32-х битный адрес IP; для CH - имя домена и последующий 16-битный адрес Chaos CNAME - имя домена MX - 16-битное значение приоритета, за которым следует имя узла, работающего как почтовый шлюз для домена - владельца NS - имя узла PTR - имя домена SOA - несколько полей

Поле TTL интерпретируется как предел времени хранения RR в кэше. TTL не применяется для авторитетных данных внутри зоны. Для авторитетных данных внутри зоны применяется специальная временная организация. TTL назначается администратором для зоны, из которой поступают данные. TTL=0 запрещает кэширование данных. Так, записи SOA всегда имеют TTL=0. Если ожидается изменение RR, перед проведением изменения ее TTL может быть уменьшено для сокращения периода несоответствия во время замены. После проведения замены TTL увеличивается обратно до прежнего значения.

Данные в разделе RDATA хранятся как комбинация бинарных строк и имен домена. Имена домена часто используются как указатели на другие данные системы имен.

5.3.2. Формат представления RR в сообщении DNS

5.3.2.1. Формат RR приведен на рис. 3.

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15

NAME

TYPE
CLASS
TTL

RDLENGTH
RDATA

Рисунок. 3. Формат представления RR

Описание значений полей формата RR приведено в табл. 3.

Таблица 3

Описание значений полей формата RR

Поле	Длина, октет	Значение
NAME	-	Доменное имя владельца в печатной форме согласно п. 6.2.1.2.
TYPE	2	Тип RR
CLASS	2	Класс RR
TTL	4	32-битовое целое со знаком - время жизни
RDLENGTH	2	16-битовое целое без знака - длина поля RDATA в октетах
RDATA	-	Описание ресурса в соответствии со значениями TYPE и CLASS

5.3.2.2. Значения поля TYPE должны соответствовать табл. 4.

Таблица 4

Значения поля TYPE

Тип	Значение	Описание
Значения, разрешенные в запросе и ответе
A	1	адрес узла
NS	2	авторитетный сервер имен
CNAME	5	каноническое имя для псевдонима
SOA	6	отметка начала авторитетной зоны
WKS	11	описание сервиса
PTR	12	указатель доменного имени
HINFO	13	информация об узле
MINFO	14	информация о почтовом ящике или списке рассылки
MX	15	почтовый шлюз
TXT	16	текстовая строка

Значения, разрешенные только в запросе (значения поля QTYPE)
AXRF	252	запрос пересылки целой зоны
*	255	запрос всех записей

5.3.2.3. Значения поля CLASS

Значения поля CLASS приведены в табл. 5.

Таблица 5

Значение поля CLASS

Тип	Значение	Описание
Значения, разрешенные в запросе и ответе
IN	1	Internet
CH	3	CHAOS
HS	4	Hesiod
Значения, разрешенные только в запросе (значения поля QCLASS)
*	255	любой класс

5.3.2.4. Формат и значения поля RDATA

Все символы должны быть закодированы в ASCII

domain-name ::= <имя домена во внутренней форме представления>

Xbit ::= <бит>

0bit ::= <бит, установленный в 0>

unsigned_int32 ::= 32(Xbit) ; 32-разрядное целое без знака

Поле RDATA может иметь следующие типы форматов: CNAME-RDATA, HINFO-RDATA, MX-RDATA, NS-RDATA, PTR-RDATA, SOA-RDATA, TXT-RDATA, A-RDATA, WKS-RDATA.

5.3.2.4.1. CNAME-RDATA ::= domain-name

; domain-name содержит каноническое имя владельца. Имя владельца является псевдонимом.

5.3.2.4.2. HINFO-RDATA ::= CPU OS

CPU ::= character-string ; указывает на тип процессора

OS ::= character-string ; указывает операционную систему

; значения CPU и OS должны соответствовать RFC-1700[9]

5.3.2.1.3. MX-RDATA ::= preference exchange

preference ::= <16-битное целое> ; приоритет данной RR

; по отношению к другим RR того же владельца

exchange ::= domain-name ; узел почтового шлюза для данного

; владельца

; запись MX влечет образование дополнительной секции типа A

; для узла, указанного как шлюз

5.3.2.1.4. NS-RDATA ::= NSDNAME

NSDNAME ::= domain-name ; авторитетный узел для данного

; класса или домена

; NS RR объявляет, что узел с указанным именем имеет

; зону в указанном классе , начинающуюся от имени владельца

;

; Запись NS влечет образование обычной дополнительной

; секции для размещения записи типа A и,

; в случае использования в ссылке, специальный поиск зоны,

; в которой они будут располагаться в качестве " клеевых"

; данных

5.3.2.1.5. PTR-RDATA ::= PTR DNAME

PTRDNAME ::= domain-name ; указывает на некоторую позицию

; в пространстве доменных имен

; данные RR используются в особых доменах для указания на

; некоторые другие позиции в доменном пространстве

; (например, данные RR используются в домене IN-ADDR.ARPA

5.3.2.1.6. SOA-RDATA ::= MNAME RNAME SERIAL REFRESH

RETRY EXPIRE MINIMUM

MNAME ::= domain-name ; сервер имен, являющийся первичным

; для данной зоны

RNAME ::= domain-name ; почтовый ящик лица, ответственного

; за данную зону

SERIAL ::= unsigned_int32 ;номер версии первичной копии зоны

REFRESH ::= unsigned_int32 ;временной интервал перед тем,

; как данные о зоне должны быть

; обновлены

RETRY ::= unsigned_int32 ; временной интервал перед

; повтором неудачного запроса

EXPIRE ::= unsigned_int32 ; временной интервал от момента

; последнего обновления копии зоны,

; в течение которого эта копия

; считается авторитетной

MINIMUM ::= unsigned_int32 ; минимальное значение TTL,

; для экспортируемых RR данной зоны

; Единицы всех временных значений - секунды.

; Значение MINIMUM является нижней границей для значений TTL

; всех записей в данной зоне

5.3.2.1.7. TXT-RDATA ::= 1*(character-string)

5.3.2.1.8. A-RDATA ::= ADDRESS

ADDRESS ::= <32-битный адрес IP>

; Узлы, имеющие несколько адресов IP, имеют несколько

; записей RR A

; в контрольном файле A-RDATA хранится как 4 десятичных

; числа, разделенных точками без пробелов.

5.3.2.1.9. WKS-RDATA ::= ADDRESS PROTOCOL BIT-MAP

ADDRESS ::= <32-разрядный адрес IP>

PROTOCOL ::= 8(Xbit) ; номер протокола IP

BIT-MAP ::= *(8(Xbit)) ; битовая маска

; запись WKS предназначена для описания хорошо известных

; сервисов, поддерживаемых отдельным протоколом на отдельных

; адресах IP

; Битовая маска указывает порт протокола. Первый бит

; соответствует 0-му порту, второй - 1-му и т.д.

; Значения номеров протоколов и портов должны

; соответствовать RFC 1700 [9]

5.3.3. Формат RR в контрольных файлах

Большинство RR занимают единственную строку, хотя возможны строки продолжения с использованием скобок.

Для улучшения читаемости могут быть включены пустые строки.

Начало строки указывает владельца. Если начало строки пустое, тогда владелец предполагается таким же, как и в предыдущей RR.

Далее идут TTL, класс и тип .

Более подробно формат RR в контрольном файле описан в п. 6.4.4.

5.3.4. Шаблоны

Имя владельца в записи RR может начинаться с символа "*". Такие RR называются шаблонами. Наиболее часто шаблоны используются для создания зон, которые в свою очередь, используются для перенаправления почты из Internet в некоторую другую почтовую систему. Любое имя, соответствующее шаблону, будет принадлежать такой зоне и обладать определенными свойствами согласно данным, указанным в RR с шаблоном, если только не существует RR, точно соответствующий имени.

Шаблоны не применяются, когда:

- запрос принадлежит другой зоне,

- известно, что существует запрашиваемое имя либо имя между запрашиваемым именем и шаблоном.

Например, если есть RR - шаблон с именем владельца "*.X" и в данной зоне также содержатся RR, прикрепленные к B.X, шаблоны будут применяться к запрашиваемому имени Z.X, но не к запрашиваемому имени B.X, A.B.X или X.

Символ "*" в запрашиваемом имени не имеет специального значения, но может использоваться для тестирования шаблонов в авторитетной зоне. Запрос с "*" является единственным способом получить ответ, содержащий RR - шаблоны. Результат такого запроса не должен кэшироваться.

Пример использования шаблонов:

Пусть существует большая компания с большой сетью не-TCP/IP. Эта компания хочет создать почтовый шлюз. Если компания названа X.COM, и шлюз TCP/IP назван A.X.COM, то в зону COM могут быть введены следующие записи RR.

X.COM MX 10 A.X.COM

*.X.COM MX 10 A.X.COM

A.X.COM A 1.2.3.4

A.X.COM MX 10 A.X.COM

*.A.X.COM MX 10 A.X.COM

Данные записи будут заставлять сервер на любой запрос MX для любого доменного имени, заканчивающегося X.COM возвращать запись MX RR, указывающую на A.X.COM. Последний шаблон необходим, так как действие первого шаблона перекрывается 4-й строкой.

5.4. Взаимодействие по протоколу DNS

Взаимодействие по протоколу DNS осуществляется путем обмена сообщениями DNS и контрольными файлами DNS.

5.4.1. Формат сообщений DNS

При взаимодействии по протоколу DNS путем обмена сообщениями DNS одна взаимодействующая сторона DNS, которая инициирует соединение, называется клиентом, а

другая - сервером. Взаимодействие по протоколу DNS заключается в том, что клиент посылает серверу сообщения-запросы, а сервер выдает сообщения-ответы на запросы клиента. Сообщения DNS имеют единый формат.

Формат сообщения DNS должен соответствовать рис. 4

Заголовок	Header
Запрос	Question	Вид запроса серверу имен
Ответ	Answer	Записи RR, содержащие ответ
Авторитетный	Authority	Записи RR, указывающие на авторитетный сервер
Дополнительно	Additional	Записи RR, содержащие дополнительную информацию

Рисунок. 4. Формат сообщения DNS

Секция заголовка является обязательной.

Формат заголовка показан на рис. 5.

Opcode

RCODE

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

Рисунок. 5. Формат заголовка DNS

Описание полей заголовка DNS приведено в табл. 6.

Таблица. 6

Описание полей заголовка DNS

Обозначение	Длина, бит	Описание
ID	16	Идентификатор, генерируемый источником запроса. Указывается в соответствующем ответе.
QR	1	0 – запрос 1 – ответ
OPCODE	4	Тип запроса: 0 - стандартный (QUERY) 1 - инверсный (IQUERY) от 3 до 15 – зарезервировано
AA	1	Авторитетный ответ. Показывает, что ответ выдан авторитетным сервером для домена, к которому относится указанное в запросе имя.
TC	1	Показывает, что сообщение было усечено в связи с превышением длины допустимого сообщения для канала передачи.
RD	1	Желательна рекурсия. Если установлен в запросе, это показывает серверу имен, что данный запрос нужно обрабатывать рекурсивно. Копируется в ответ.
RA	1	Рекурсия доступна. Устанавливается в ответе, если сервер поддерживает рекурсию.
Z	3	Зарезервировано
RCODE	4	Код ответа 0 - нет ошибки 1 - ошибка формата запроса 2 - внутренняя ошибка сервера 3 - ошибка имени (только для авторитетного сервера) 4 - данный вид запроса не реализован 5 - Отказ выполнения операции от 6 до 15 – зарезервировано
QDCOUNT	16	целое без знака, указывающее количество позиций в секции " запроса"
ANCOUNT	16	целое без знака, указывающее количество RR в секции " ответа"
NSCOUNT	16	целое без знака, указывающее количество RR в секции " авторитетный"
ARCOUNT	16	целое без знака, указывающее количество RR в секции "д ополнительно"

Формат секции запроса показан на рис. 6.

QNAME

QTYPE

QCLASS

Рисунок. 6. Формат секции запроса

Описание формата секции запроса приведено в табл. 7.

Таблица 7

Формат секции запроса

Обозначение	Длина, октет	Описание
QNAME	-	Имя домена во внутренней форме согласно 6.2.1.1.
QTYPE	2	код типа запроса
QCLASS	2	код класса запроса

5.4.2. Типы запросов и соответствующие им ответы

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

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

Тип запроса определяется значением 4-битного поля заголовка opcode. O pcode может иметь значения, трактуемые как стандартный запрос, инверсный запрос или запрос статуса.

Четыре секции запроса, следующие за заголовком, описаны в табл. 8.

Таблица 8

Секции запрса, следующие за заголовком

Question	Вопрос	Содержит имя запроса и параметры запроса
Answer	Ответ	Содержит записи RR, прямо отвечающие на запрос
Authority	Авторитетный	Содержит записи RR, которые описывают другие авторитетные серверы. Может (необязательно) содержать SOA RR для авторитетных данных в секции Ответ.
Additional	Дополнительно	Содержит записи RR, которые могут быть полезны при использовании записей RR, содержащихся в других секциях.

Содержание секций зависит от кода поля opcode.

5.4.2.1. Стандартные запросы

Стандартный запрос представляет собой целевое доменное имя QNAME, тип запроса (QTYPE) и класс запроса (QCLASS). Выполнение его предполагает возвращение соответствующих записей RR. Длина полей QTYPE и QCLASS составляет 16 бит.

Поле QTYPE может содержать значения, приведенные на рис. 7.

<any type>	<любой тип>	подходит только данный тип записи
AXFR		специальная передача зоны QTYPE
*		подходят все типы записей RR

Рисунок 7. Значения поля QTYPE

Поле QCLASS может содержать значения, приведенные на рис. 8.

<any class>	<любой класс>	подходит только данный класс записи
*		подходят все классы записей RR

Рисунок 8. Значения поля QTYPE

Кроме информации, жестко удовлетворяющей условию запроса, сервер может возвращать в ответе некоторую дополнительную информацию.

Примечание: ответ на запрос с полем типа QTYPE, содержащим "*", никогда не будет авторитетным, так как отдельный сервер не имеет информации, является ли ответ авторитетным для всех классов.

5.4.2.2. Инверсные запросы

Сервер имен может поддерживать инверсные запросы. Если сервер имен не поддерживает инверсный запрос, на подобный запрос он должен выдать ответ "Не реализовано" (Not-implemented).

Инверсный запрос должен содержать единственную RR в секции ответа. Поля owner и TTL являются незначащими. Выдаваемый ответ должен содержать запросы в секции запроса, определяющие все имена, информацию о которых данный сервер имен имеет. Так как ни один сервер имен не обладает полной информацией обо всем домене, никогда нельзя сказать, является ли полным ответ на инверсный запрос.

В ответ на инверсный запрос сервер имен должен выдать:

- 0, одно или несколько доменных имен в секции QNAMES для указанного ресурса;

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

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

В ответе на инверсный запрос может не содержаться истинный TTL, и могут не указываться случаи, когда идентифицированная RR является одной из множества. Поэтому записи RR, получаемые из ответов на инверсные запросы, не должны кэшироваться.

5.4.3. Сжатие сообщений

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

Формат указателя должен соответствовать рис. 9.

OFFSET

Рисунок. 9. Формат указателя

Первые два бита позволяют различать октеты указателя и октет длины метки. Поле OFFSET указывает на смещение в байтах от начала сообщения (то есть первого октета поля ID заголовка сообщения).

Метод сжатия позволяет доменному имени в сообщении быть представленным в одной из трех форм:

- доменное имя во внутреннем формате - последовательность меток с нулевым октетом в конце

- указатель

- последовательность меток с указателем в конце.

Реализация метода сжатия сообщений является не обязательной.

5.4.4. Контрольные файлы

Контрольные файлы - это текстовые файлы, содержащие записи RR в текстовой форме.

5.4.4.1. Формат контрольного файла

Контрольный файл состоит из набора записей.

Возможен перенос записи на следующую строку с использованием скобок.

Комментарии начинаются с символа ";" ( точка с запятой) .

Символы пробелов и табуляции выполняют функции разделителей между элементами позиции.

В контрольном файле могут быть записи следующего формата:

entry ::= ( <SP> [ comment ] ) /

( $ORIGIN <SP> domain-name [ <SP> comment] ) /

( $INCLUDE <SP> file-name [ <SP> domain-name ]

[comment] ) /

( domain-name rr [ <SP> comment]) /

( <SP> rr [ comment] )

<SP> ::= (<SP> (" " / <TAB>)) / (" " / <TAB>)

Пустые строки с комментариями и без комментариями допустимы в любом месте контрольного файла.

domain-name - имя домена в символьной форме.

Имена доменов, заканчивающиеся символом "." ( точка) , называются абсолютными и считаются полными именами.

Доменные имена, не заканчивающиеся символом "." ( точка) , называются относительными.

Полное доменное имя получается соединением относительного имени и текущего основания относительного имени. Употребление относительного имени в случае неустановленного основания является ошибкой.

Позиция $ORIGIN переустанавливает текущее основание относительного доменного имени.

Позиция $INCLUDE вставляет указанный файл в текущий контрольный файл. Позиции $ORIGIN вставляемого файла не оказывают влияния на текущее основание относительного имени в родительском контрольном файле.

Элемент rr обозначает представление записи RR.

rr ::= ( [TTL] [ <SP> class ] <SP> type <SP> RDATA ) /

( [class] [ <SP> TTL ] <SP> type <SP> RDATA )

Если поля TTL или class пропущены, то берутся предыдущие точно объявленные значения.

5.4.4.2. Использование специальных символов в контрольном файле

Строка символов (character-string) может быть представлена непрерывным набором символов без пробелов внутри или произвольным набором символов с пробелами, заключенным в двойные кавычки. Во втором случае, если в исходной строке встречается символ кавычки, перед ним должен быть вставлен символ \.

Возможны следующие специальные символы:

@ используется для указания на текущее основание относительного имени.

\X где Х - любой символ, кроме цифры от 0 до 9, используется для квотирования символа X, так что специальный символ X используется в качестве печатного символа, а не специального.

\DDD где каждая D - это цифра, используется для обозначения октета, содержащего значение, соответствующее десятичному числу DDD

( ) (символы круглые скобки) используются для группирования данных, занимающих больше одной линии (то есть внутри которых содержатся символы <CRLF>)

; (символ точка с запятой) используется для обозначения начала комментария.

5.4.4.3. Использование контрольного файла для определения зон

При составлении контрольного файла, определяющего зону должны быть учтены следующие моменты:

- Все RR файла должны иметь один и тот же класс

- Должна присутствовать только одна запись SOA RR

- Если есть поддомены, и требуется " клеевая" информация, то она должна присутствовать.

Пример контрольного файла, содержащего одну зону:

@ IN SOA VENERA Action\.domains (

20 ; SERIAL

7200 ; REFRESH

600 ; RETRY

3600000; EXPIRE

60) ; MINIMUM

NS A.ISI.EDU.

NS VENERA

NS VAXA

MX 10 VENERA

MX 20 VAXA

A A 26.3.0.103

VENERA A 10.1.0.52

A 128.9.0.32

VAXA A 10.2.0.27

A 128.9.0.33

5.5. Разрешающая система

5.5.1. Функции разрешающей системы

Разрешающая система используется для организации рекурсивных запросов и кэширования запросов и ответов. В случае, если в состав сервера имен входит разрешающая система, он называется рекурсивным. Если в состав сервера имен входит разрешающая система, разрешающая система выполняет функции интерфейса с клиентом.

Клиентский интерфейс разрешающей системы выполняет три основные функции:

- трансляция имени в адрес узла

- трансляция адреса в имя узла

- функция общего поиска

В качестве ответа клиенту разрешающая система может выдать:

- одну или несколько RR

- ошибку имени NE

- ошибку "данные не найдены"

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

5.5.2. Алгоритм работы разрешающей системы.

5.5.2. 1. Шаг 1. Проверить, есть ли ответ на запрос в локальной информации. Если есть, выдать ответ клиенту. Поиск происходит в кэшированных данных. Если данные найдены, они предполагаются подходящими для нормального использования. Разрешающие системы могут форсированное игнорирование кэшированных данных по запросу клиента.

5.5.2. 2. Шаг 2. Найти наилучшие серверы для продолжения запроса. Поиск серверов имен и занесение их в SLIST. Сначала в локально доступных NS RR серверов имен, ищется SNAME, затем имя родительского домена SNAME, затем прародительского и т.д. до корня. Если поиск заканчивается неудачей, разрешающая система инициализирует SLIST из SBELT.

5.5.2. 3. Шаг 3. Отправить запросы и ждать, пока не придет ответ хотя бы на один из них.

5.5.2. 4. Шаг 4. Анализировать ответ:

если ответ удовлетворяет запросу или содержит ошибку имени, данные кэшируются и возвращаются клиенту

если ответ содержит лучшую ссылку на другие серверы, кэшировать ссылочную информацию и перейти к шагу 2

если ответ показывает CNAME и не удовлетворяет запросу, кэшировать CNAME, заменить SNAME на каноническое имя из CNAME RR и перейти к шагу 1

если ответ показывает ошибку сервера или другую ненормальную информацию, удалить имя сервера из SLIST и вернуться к шагу 3.

5.5.3. Кэширование отрицательных ответов.

Режим работы DNS с кэшированием отрицательных ответов с установленным TTL является необязательным. Данная возможность является особенно важной в системах, реализующих сокращенные имена (naming shorthands) и использующих списки поиска, так как может случится, что для популярного сокращения в конце списка поиска потребуется суффикс, и таким образом будет генерироваться множество ошибок имен там, где это используется.

5.5.4. Работа разрешающей системы с псевдонимами

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

5.5.5. Рекурсивный режим работы сервера

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

- во всех ответах сервера устанавливается в " 1" бит RA - рекурсия доступна.

- запрос клиента содержит бит RD - рекурсия желательна.

Если установлены оба бита RA и RD, то при необходимости используется режим рекурсии.

Возможны следующие варианты ответов:

1. Рекурсия разрешена

- ответ на запрос, возможно предшествуемый одной или двумя CNAME RR

- ошибка имени, указываемая, что имя не существует. Может включать CNAME RR, указывающую, что запрос содержал псевдоним, для которого не существует канонического имени.

- индикация временной ошибки

2. Рекурсия запрещена

- ошибка имени, указывающая, что имя не существует

- индикация временной ошибки

- некоторая комбинация:

RR, отвечающих на запрос вместе с информацией, являются ли эти RR кэшированными

Ссылка на сервер имен

- дополнительные RR, являющиеся по мнению сервера полезными запросчику.

Приложение 5

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу http

1. Область применения

Настоящее приложение описывает технические требования к ТС службы доступа к информационным ресурсам а по протоколу HTTP в соответствии с RFC 2068 [14] .

В приложении приведены операции взаимодействия клиента с различными типами ресурсов сети передачи данных, доступ к которым осуществляется посредством сервера HTTP. Определяются операции получения клиентом содержимого ресурса, согласования представления ресурса, передачи информации клиента на адрес ресурса , идентификации клиента.