RFC-1034. Система именовния сегментов/областей. Концепция и общая характеристика (DNS). Ноябрь 1987 года (категория: стандарт)

Подождите немного. Документ загружается.

Следовательно, почтовый сервер “HOSTMASTER@SRI-NIC.ARPA” будет

представлен в форме DNS-имени как “HOSTMASTER.SRI-NIC.ARPA”.

Обычный пользователь не принимает участие в определении этих правил,

но ему необходимо понимать, что эти правила являются результатом

многочисленных компромиссов между желанием усовершенствовать систему и

старой схемой применения, согласований между различными системами

определения объектов, и неизбежным стремлением добавить новые свойства

при определении правил. Цель DNS-системы — обеспечение какого-либо

объекта, который зачастую является более критичным, чем свойственные для

DNS-системы ограничения.

2.4. Пример пространства имен

На рис.1 представлена часть пространства имен существующего сегмента

(которое часто используется в этом стандарте). (Замечание. Эта древовидная

структура является очень малой частью реального пространства имен.)

Рис.1. Пример структурного дерева пространства имен

В данном примере, корневой сегмент имеет три прямых субсегмента

(субсегменты-братья): “MIL”, “EDU” и “ARPA”. Сегмент “LCS.MIT.EDU”

имеет только один прямой субсегмент “XX.LCS.MIT.EDU”. Все “листья” этого

структурного дерева также являются сегментами.

2.5. Синтаксис привилегированных имен

MIL ARPAEDU

DARPANOSCBRL SRI-NICIN-ADDR ACC

UCI MIT ISI UDEL YALE

LCS ACHILLES

AXX C VAXA VENERA Mockapetris

DNS-спецификация является максимально общей с точки зрения правил

конструирования DNS-имен. Существует идея, в соответствии с которой имя

любого существующего объекта может быть представлено как DNS-имя,

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

DNS-имя, то тогда предусмотрительный пользователь будет выбирать имя,

которое удовлетворяло бы и правилам DNS-системы, и существующим

правилам именования объекта (последние правила либо опубликованы, либо

подразумеваются существующими прикладными программными модулями).

Например, когда сегменту/области почтовой службы присваивается

DNS-имя, то тогда пользователю необходимо учитывать правила данного

стандарта и правила в RFC-822. Когда формируется имя нового IP-узла,

необходимо придерживаться старых правил для системы IP-узлов

“HOSTS.TXT”. Это позволит избежать проблемы, связанные с необходимостью

преобразования старых программных модулей для применения DNS-имен.

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

возникнуть во многих прикладных службах, которые используют DNS-имена

(например, e-mail, TELNET):

<domain> ::= <subdomain> | " "

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= — любой из 52 буквенных символов от “А” до “Z” в верхнем

регистре и от “а” до “z” в нижнем регистре;

<digit> ::= — любое число от “0” до “9”.

(Замечание. В DNS-именах допускаются символы и в нижнем, и в

верхнем регистре, однако, регистр не имеет никакого смысла. То есть,

пара имен с одинаковым буквенным значением, но разными регистрами

трактуется как пара идентичных имен.)

Для маркеров должно применяться правило, которое используется для

имен IP-узлов сети “ARPANET”. Они должны начинаться с буквы,

заканчиваться буквой или цифрой и состоять только из букв, цифр и дефиса. На

длину маркеров также существуют некоторые ограничения. Они должны быть

длиной 63 символа или меньше.

Например, следующие последовательности символов идентифицируют

IP-узлы в Internet: “A.ISI.EDU”, “XX.LCS.MIT.EDU”, “SRI-NIC.ARPA”.

2.6. Записи информационных ресурсов ( RR )

DNS-имя идентифицирует узел. Каждый узел имеет набор

информационных ресурсов, который, в принципе, может быть пустым. Набор

информационных ресурсов, связанный с соответствующим именем, состоит из

отдельных записей об информационных ресурсах (Resource Records — RRs).

Порядок следования RRs в наборе не имеет значения, и поэтому нет

необходимости его соблюдать DNS-серверами, DNS-клиентами или другими

элементами DNS-системы.

Когда идет речь об определенной RR, то тогда подразумевается, что она

включает следующие элементы:

 “Владелец” (“owner”) — представляет собой DNS-имя, которое

определяет место в сети, где искать RR;

 “Тип” (“type”) — представляет собой 16-битовое кодовое значение,

которое определяет тип записи в этой RR. Типы указывают на

абстрактные информационные ресурсы. В данном стандарте

используются следующие типы записей:

 “А” — адрес IP-узла;

 “CNAME” — определяет каноническое имя (прозвище, кличка,

общеупотребимое имя);

 “HINFO” — определяет тип процессора и тип операционной системы,

используемых IP-узлом;

 “MX” — определяет наличие обмена почтовыми сообщениями для

сегмента/области (RFC-974);

 “NS” — определяет авторизованный DNS-сервер для сегмента/области;

 “PTR” — указатель на другую (IP-адресную) часть пространства имен

сегмента/области;

 “SOA” (“The start of a zone of authority”) — определяет начало зоны

ответственности;

 “Класс” (“class”) — представляет собой 16-битовое кодовое значение,

которое определяет семейство протоколов или пример протокола. В

данном стандарте используются следующие классы:

 “IN” — определяет Internet-систему;

 “CH” — определяет хаотичную систему;

 “Время жизни RR” (“TTL — Time to Live”) — определяет время жизни

RR. Это поле содержит 32-битовое целое число, определяющее

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

когда они содержат в своей кэш-памяти RR. Это значение указывает на

время, в течение которого RR может храниться в кэш-памяти, перед тем

как ее уничтожат;

 “Данные об информационном ресурсе” (“RDATA”) — определяет тип, а

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

информационный ресурс:

 “А” — для класса “IN” — это 32-битовый IP-адрес, для класса “CH” —

DNS-имя, за которым следует 16-битовый восьмизначный адрес

хаотичной системы;

 “CNAME” — DNS-имя;

 “MX” — 16-битовая наиболее предпочтительная величина (чем

меньше, тем лучше), за которой следует название IP-узла,

обеспечивающего обмен почтовыми сообщениями в интересах

соответствующего сегмента/области;

 “NS” — имя IP-узла;

 “PTR” — DNS-имя;

 “SOA” — несколько полей.

Имя владельца сегмента/области, как правило, только подразумевается,

вместо того, чтобы образовывать целую часть RR. Например, большинство

DNS-серверов формируют внутреннюю древовидную или смешанную

структуру для пространства имен и “сцепляют” RR-записи из узлов.

Оставшиеся части RR представляют собой фиксированный заголовок (type,

class, TTL), который согласуется со всеми RR-записями, и переменную часть

(RDATA), которая соответствует требованиям, предъявляемым определенным

информационным ресурсом.

Поле TTL содержит значение временного интервала, в течение которого

RR может храниться в кэш-памяти. Это время никак не связано с

авторизованными данными в зонах. Оно также выступает в роли тайм-аута, но

регулируется в соответствии со стратегией обновления данных в конкретной

зоне. TTL назначается администратором зоны, в которой находятся источники

данных. Несмотря на то, что TTL может быть использовано для минимизации

процедуры кэширования, а нулевое значение TTL вообще запрещает

использование кэш-функции, реальности современного Internet предполагают,

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

Если изменение данных может произойти раньше намеченного срока, то тогда

TTL может быть уменьшено еще до проведения этого изменения с целью

минимизации каких-либо проблем (противоречий) в период проведения

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

значения при последующем обновлении данных.

Данные в разделе RDATA в записи RR представляют собой комбинацию

бинарных последовательностей и DNS-имен. DNS-имена очень часто

используются как “указатели” (“pointers”) на другие данные в DNS-системе.

2.6.1. Текстуальное представление RR

RRs представлены в бинарной форме как пакеты DNS-протокола, а при

хранении в DNS-сервере или в системе DNS-клиента они представлены

специализированном формате кодирования. В данном случае в качестве

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

показа содержания RRs. В этом формате, большинство записей об

информационных ресурсах представлены в форме одной строки, несмотря на

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

Начало строки определяет владельца RR. Если строка начинается с

пробела, то это означает, что владелец записи тот же самый, который был

указан в предшествующей RR. Очень часто пробелы используются для

улучшения читабельности.

За элементом “Владелец” следуют элементы: TTL, тип и класс RR.

Структуры полей “класс” и “тип” были описаны выше, TTL представляет собой

целое число, расположенное перед полем “тип”. Для того чтобы избежать

неоднозначность, поля “тип” и “класс” разделены между собой, поля TTL —

целые числа, а поле “тип” всегда последнее. Значения класса “IN” и TTL очень

часто пропускаются, например, в интересах прозрачности записи.

Данные о ресурсе или элемент “RDATA” из RR представлены на основе

знаний о типовом формате этих данных.

Например, RR, транслируемой в сообщении:

ISI.EDU. MX 10 VENERA.ISI.EDU.

MX 10 VAXA.ISI.EDU.

VENERA.ISI.EDU. A 128.9.0.32

A 10.1.0.52

VAXA.ISI.EDU. A 10.2.0.27

A 128.9.0.33

Поле “МХ” в RR имеет поле “RDATA”, которое состоит из 16-битового

номера, следующего за DNS-именем. Поле “адрес” RR содержит стандартный

32-битовый IP-адрес. В этом примере показаны шесть RRs, по две записи на

каждое из трех DNS-имен.

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

XX.LCS.MIT.EDU, каждый для своего класса:

XX.LCS.MIT.EDU. IN A 10.0.0.44

CH A MIT.EDU. 2420

2.6.2. Псевдонимы и канонические имена

В существующих системах, IP-узлы и другие источники

информационных ресурсов очень часто имеют несколько имен, которые

идентифицируют одни и те же ресурсы. Например, имена “C.ISI.EDU” и “USC-

ISIC.ARPA” указывают на один и тот же IP-узел. То же самое и в случае

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

фактически указывают на один и тот же почтовый сервер.

Большинство из этих систем имеют собственный взгляд, который

предполагает наличие только одного канонического или первичного имени

среди всех равнозначных имен, а все остальные в этом множестве являются

псевдонимами.

DNS-система обеспечивает дальнейшее использование таких

канонических имен (the canonical name — CNAME) RR. Каноническое имя

определяет владельца этого имени в качестве псевдонима, а также определяет

соответствующее каноническое имя в блоке (элементе) “RDATA” RR. Если на

IP-узле представлено CNAME RR, то тогда не целесообразно представлять

иные данные. Это еще раз подтверждает, что каноническое имя и его

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

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

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

Наличие CNAME в RR влечет за собой специальную процедуру,

реализуемую программным DNS-модулем. Когда DNS-сервер не может найти

затребованную запись в наборе ресурсов, связанном с DNS-именем, то тогда он

проверяет наличие блока CNAME соответствующего класса в этом наборе.

Если он присутствует, то тогда DNS-сервер включает это CNAME в ответное

сообщение и повторяет запрос на предмет определения DNS-имени, которое

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

правила, а именно, запросы, которые имеют целью сравнения типа CNAME, не

повторяются.

Например, предположим, что DNS-сервер обрабатывал запрос на предмет

определения данных типа “А” для USC-ISIC.ARPA, имея при этом следующие

записи об информационных ресурсах:

USC-ISIC.ARPA IN CNAME C.ISI.EDU

C.ISI.EDU IN A 10.0.0.52 .

Обе из этих записей будут направлены в ответных сообщениях на запрос

данных “А” типа, несмотря на то, что на запрос данных “CNAME” типа или “*”

целесообразно направлять только CNAME.

Целесообразно, чтобы DNS-имена в RRs, которые указывают на другое

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

весьма сложные (не прямые) варианты доступа к информации. Например,

адрес, указанный в записи для конкретного имени, в интересах IP-узла более

высокого уровня иерархии, целесообразно представить следующим образом:

52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU,

что более правильно по сравнению с указанием на USC-ISIC.ARPA. Конечно,

исходя из принципа надежности, программный DNS-модуль не должен

“выходить из строя”, если имеет место CNAME с многозвенным или петлевым

маршрутом. CNAME с многозвенным маршрутом должно быть передано

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

сигнал о наличии ошибки.

2.7. Запросы

Запросы представляют собой сообщения, которые могут быть переданы

на DNS-сервер для генерации ответного сообщения. В Internet такие запросы

передаются с помощью UDP-блоков или ТСР-соединений (с использованием

ТСР-блоков). Ответные сообщения DNS-сервера либо представляют собой

ответ на вопрос, сформулированный в запросе, либо они содержат новое

требование/запрос, направляемое другой группе DNS-серверов, либо

указывают на наличие ошибки.

В общем, пользователь не формирует запросы напрямую, но вместо этого

он направляет запрос DNS-клиенту, который поочередно передает один или

более запросов на DNS-серверы и разрешает проблемы, связанные с ошибками.

Конечно, возможные вопросы в сообщениях-запросах, на которые могут быть

даны ответы, определяют тип обслуживания, который может обеспечить DNS-

клиент.

DNS-запросы и ответы на них транслируются в форме стандартного DNS-

сообщения. Формат такого сообщения имеет заголовок, содержащий несколько

фиксированных (стандартных) полей, которые всегда присутствуют в

сообщениях, и четыре элемента, которые содержат параметры запроса и записи

об информационных ресурсах.

Наиболее важным полем в заголовке является 4-битовой поле,

называемое “opcode” (код сообщения), с помощью которого можно

классифицировать все запросы. Из 16-ти возможных значений этого поля

различают: одно значение (стандартный запрос) является частью логической

характеристики официального протокола, два значения (обратный запрос и

запрос состояния) являются дополнительными функциями, одно значение

(окончание/завершение) является устаревшим, а остальные не определены.

В DNS-сообщениях содержаться следующие четыре элемента (блока):

 “Вопрос” (“Question”) — содержит название запроса и другие параметры

запроса;

 “Ответ” (“Answer”) — содержит RRs, которые прямо отвечают на запрос;

 “Авторизация” (“Authority”) — содержит RRs, которые определяют

другие авторизованные серверы. Может дополнительно содержать блок

“SOA” из RR в интересах авторизованных данных, содержащихся в

элементе “Вопрос”;

 “Дополнение” (“Additional”) — содержит RRs, которые могут быть

полезны при использовании RRs в других элементах DNS-сообщения.

(Замечание. Содержание этих блоков (но ни их формат) варьируется

в зависимости от значения в поле “opcode”.)

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

Стандартный запрос определяет целевое DNS-имя (QNAME), тип запроса

(QTYPE), класс запроса (QCLASS) и запрашиваемые для сравнения RRs. Этот

тип запроса включает в себя большинство всех DNS-запросов, которые

подразумеваются под термином “запрос”, предназначенного для обозначения

стандартного запроса, если же, конечно, он не имеет иного определения. Поля

“QTYPE” и “QCLASS” имеют 16-битовую длину, каждое, и представляют

собой расширенное множество определенных типов и классов.

Поле “QTYPE” может содержать следующие значения:

 “<any type>” (любой тип) — проверяется только этот тип записи об

информационном ресурсе (например, “А”, “PTR”);

 “AXFR” — специализированная зона доставки “QTYPE”;

 “MAILB” — проверяются все имена почтовых серверов, связанных с

RRs (например, “MB” и “MG”)

 “*” — проверяются все типы RR.

Поле “QCLASS” может содержать следующие значения:

 “<any class>” (любой класс) — проверяется только этот класс

(например, “IN”, “CH”);

 “*” — проверяются все классы RR.

На основе запросов DNS-имени, “QTYPE” и “QCLASS” DNS-сервер

осуществляет поиск RRs, необходимых для сравнения (проверки). Кроме этого,

DNS-сервер может возвращать в ответе дополнительные RRs, которые

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

информацией или RRs, так как последние могут быть полезны при

интерпретации дополнительных RRs. Например, DNS-сервер, не имеющий

запрашиваемой информации, может знать сервер, который ею обладает. DNS-

сервер, который возвращает в ответ DNS-имя в дополнительной RR, может

также направлять в ответном сообщении RR, связывающее это DNS-имя с

адресом.

Например, клиент почтовой службы, собираясь отправить электронное

письмо по почтовому адресу “Mockapetris@ISI.EDU”, может запросить у DNS-

клиента почтовую информацию о сегменте “ISI.EDU” путем передачи запроса,

в котором укажет: “QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN”. В блоке

“Ответ” ответного DNS-сообщения будет представлена следующая

информация:

ISI.EDU. MX 10 VENERA.ISI.EDU.

MX 10 VAXA.ISI.EDU.,

а в блоке “Дополнение” может быть представлена следующая информация:

VAXA.ISI.EDU. A 10.2.0.27

A 128.9.0.33

VENERA.ISI.EDU. A 10.1.0.52

A 128.9.0.32.

Наличие такой информации в блоке “Дополнение” объясняется

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

пожелает провести обмен почтовыми сообщениями, то вероятнее всего ей в

скором времени понадобятся адреса почтовых серверов.

(Замечание. Конструкция “QCLASS=*” требует специальной

интерпретации, так как она относится к вопросам авторизации.

Поскольку соответствующий DNS-сервер может не знать всех классов,

которые доступны в DNS-системе, он вообще может никогда не знать есть

ли авторизованные серверы для этих классов. Следовательно, ответы на

запросы вида “QCLASS=*” могут никогда не быть авторизованными.)

2.7.2. Обратные запросы ( дополнительная функция )

DNS-серверы могут также обеспечивать формирование обратных

запросов, которые отображают соответствующий ресурс в DNS-имя или DNS-

имена, принадлежащие этому ресурсу. Например, если стандартный запрос

может отображать DNS-имя в SOA RR, то соответствующий обратный запрос

может отображать SOA RR обратно в DNS-имя.

Реализация этой услуги является не обязательной для DNS-сервера, но

все DNS-серверы обязаны, по крайней мере, “понимать” сообщения с

обратными запросами и в ответ на них отправлять сообщение об ошибке

(услуга не выполнима).

DNS-система не может гарантировать полноту или уникальность

обратных запросов, так как DNS-система она организована прежде всего по

принципу именования сегментов/областей, а не по принципу адресации IP-

узлов или ресурсов другого типа. Обратный запросы полезны, в первую

очередь, для решения задач отладки и технологического обслуживания баз

данных.

Обратные запросы могут не содержать необходимое значение TTL и не

указывают на случаи, когда идентифицируемая RR является одной из

подмножества (например, один адрес для IP-узла, имеющего несколько

адресов). Более того, целесообразно, что RRs, возвращаемые в обратных

запросах, никогда не хранились в кэш-памяти.

Обратные запросы не являются приемлемым методом отображения

адресов IP-узлов в их DNS-имена. Вместо них используется сегмент “IN-

ADDR.ARPA”.

III.

DNS

СЕРВЕРЫ

3.1. Общие положения

DNS-серверы (или серверы системы именования или DNS-системы)

являются хранилищами (репозиториями) информации, которая формирует базу

данных (БД) сегмента/области. БД разделена на несколько составных частей,

называемых зонами, которые распределены среди DNS-серверов (фактически,

это территориально-распределенная БД). Так как DNS-серверы могут

выполнять несколько дополнительных функций или иметь несколько

источников данных, то тогда основной задачей DNS-сервера является

выполнение функции ответов на запросы необходимых данных в его зоне. В

соответствии с замыслом, DNS-серверы могут отвечать на запросы в простой

форме. Ответ может быть всегда сформирован с использованием только

локальной информации и содержать либо ответ на вопрос, либо ссылку на

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

запрашиваемой информации.

В любой зоне может присутствовать несколько DNS-серверов с целью

обеспечения гарантии их наличия, в случае если какой-либо IP-узел или линия

связи вышла из строя. Исходя из административных требований, в каждой зоне

должны присутствовать, по крайней мере, два сервера, а в большинстве зон

таких серверов должно быть более чем два.

Любой DNS-сервер обычно обслуживает одну или более зон, но в таком

случае он имеет возможность получить авторизованную информацию только о

небольшой части структурного дерева сегмента/области. Он также может иметь

некоторые неавторизованные данные, хранящиеся в кэш-памяти, о других

частях дерева. DNS-сервер маркирует свои сообщения в ответ на поступившие

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

ответ поступил либо из авторизованной базы данных, либо нет.

3.2. Распределение БД в зонах

БД сегмента/области делится двумя способами:

 по классической схеме;

 “разрезание” пространства имен между узлами.

Классическая схема разбиения является весьма простой. БД для одного

любого класса формируется, наделяется полномочиями и обслуживается

независимо от всех других классов. Так как, по общей договоренности,

пространства имен являются одинаковыми для всех классов, деление на классы

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

древовидными структурами пространств имен. (Замечание. Данные, которые

закрепляются за узлами, будут различными с точки зрения разных

параллельных классов.) Формирование нового класса может быть

обусловлено следующими наиболее общими причинами: необходимость нового