rd_45.134-2000 (524304), страница 16

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 16)

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

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

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

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

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

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

Таблица 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

1

OFFSET

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

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

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

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

- указатель

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

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

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

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

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

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

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

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

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

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

entry ::= ( [ comment ] ) /

( $ORIGIN domain-name [ comment] ) /

( $INCLUDE file-name [ domain-name ]

[comment] ) /

( domain-name rr [ comment]) /

( rr [ comment] )

::= ( (" " / )) / (" " / )

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

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

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

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

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

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

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

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

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

( [class] [ TTL ] type RDATA )

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

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

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

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

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

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

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

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

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

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. Работа разрешающей системы с псевдонимами

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

Характеристики

Список файлов стандарта