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

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

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

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

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

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

domain-name ::=

Xbit ::=

0bit ::=

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 ::= ; приоритет данной 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 ::= PTRDNAME

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 ::=

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

; записей RR A

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

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

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

ADDRESS ::=

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

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

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

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

ID

QR

Opcode

AA

TC

RD

RA

Z

RCODE

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

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

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

Таблица. 6

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

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

QNAME

QTYPE

QCLASS

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

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

Таблица 7

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

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