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

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

RFC 1034 ноябрь 1987

года

категория: стандарт

СИСТЕМА

ИМЕНОВАНИЯ

СЕГМЕНТОВ

ОБЛАСТЕЙ

КОНЦЕПЦИЯ

ОБЩАЯ ХАРАКТЕРИСТИКА

(

DNS

)

ВВЕДЕНИЕ

В данном стандарте рассматривается система и структура именования

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

узлах, а также протоколы и серверы, используемые в качестве средств

реализации системы именования сегментов/областей (Domain Name System —

DNS).

1.1. Краткий исторический ракурс

Толчком в развитии DNS послужил рост сети Internet:

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

стандартах RFC-952, RFC-953 Центра сетевой информации (Network

Information Center — NIC). Для использования новой версии этой схемы

необходима такая общая пропускная способность сети, которая будет

прямо пропорциональна квадрату числа IP-узлов в сети. И даже когда

используются несколько уровней FTP-системы, все равно FTP-нагрузка

на NIC-узел является чрезмерной. Стремительный рост числа IP-узлов не

предвещал ничего хорошего в будущем;

 число пользователей Internet также изменялось стремительно. Узлы

синхронизации (предоставления) доступа в сеть, которые составляли

основу ARPANET, были заменены локальными сетями, состоящими из

рабочих станций. Администраторы этих сетей использовали собственные

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

необходимые изменения в файл “HOSTS.TXT”, для того чтобы эти

изменения были доступны для всех объектов Internet. Поэтому

администраторы требовали децентрализации системы и наличия какой-

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

 прикладные службы в Internet получались более сложными и также

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

сегментов/областей общего назначения (DNS).

В ряде Internet-стандартов было представлено несколько идей о структуре

пространства имен и управления им (IEN-116, RFC-799, RFC-819, RFC-830).

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

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

отображает организационную структуру, а также имен с разделительным

символом “.” (точка), который указывает на границу между уровнями

иерархии. Проект использования распределенной базы данных и общих

информационных ресурсов (данных) был представлен в стандартах RFC-882,

RFC-883. В данном стандарте представлено дальнейшее развитие этого

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

Термины “сегмент/область” (”domain”) или “имя сегмента/области”

(“domain name”) используются и в других приложениях, не входящих в область

применения DNS-системы. Очень часто, термин “имя сегмента/области”

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

но это никак не связано с DNS-системой.

1.2. Цели разработки DNS- системы

Цели разработки DNS-системы определяют ее структуру, а именно:

 первичной целью является адаптивная конструкция пространства имен,

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

Для того чтобы избежать проблем, вызванных специальными типами

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

свою структуру сетевых идентификаторов, адресов, маршрутов или

подобной информации в качестве составного элемента имени;

 реальный размер (ёмкость) базы данных и частота обновления данных в

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

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

с целью увеличения скорости и улучшения качества обработки

информации. Конструкции, которые предполагают получение

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

более дорогостоящими и сложными, и, следовательно, от них

целесообразно отказаться. В отношении структуры пространства имен и

соответствующих способов формирования и удаления имен должен

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

были распределенными);

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

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

точностью данных, хранимых и обрабатываемых в кэш-памяти,

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

 затраты на реализацию такого средства диктуют, чтобы оно было

эффективным и полезным и не ограничивалось только одной прикладной

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

имен для восстановления (коррекции) адресов IP-узлов, почтовых адресов

и других пока неопределенных данных. Все данные, связанные с именем,

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

ограничены только одним типом данных;

 в связи с тем, что пространство имен должно быть эффективным и

полезным в различных сетях и информационных системах, необходимо

добиться применения одного и того же пространства имен различными

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

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

параллельное применение различных форматов данных одного типа

адресации;

 необходимо, чтобы процедурная характеристика информационного

обмена сервера системы именования (или просто — сервера имен) была

независима от системы связи, на которой он базируется. Некоторые

системы могут потребовать применения дейтаграммного режима

информационного обмена при передаче запросов и получении ответов,

для которого необходимо формирование только виртуального соединения

(например, обновление информации в базе данных, длинные процедуры

информационного обмена). Другие системы будут использовать

исключительно виртуальные соединения;

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

функциональных задач, решаемых IP-узлами. Целесообразно, чтобы и

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

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

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

1.3. Предположения относительно области применения DNS -системы

Организация DNS-системы является следствием некоторых

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

основе моделирования использования этой системы Internet-сообществом. Она

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

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

Эти предположения следующие:

 общая емкость единой системы баз данных первоначально будет

пропорциональна числу IP-узлов, используемых в системе, но, в

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

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

информации в DNS-системе);

 большая часть данных в системе будет изменяться очень медленно

(например, почтовые адреса, IP-адреса), но, тем не менее, целесообразно,

чтобы такая система имела способность более быстрого обновления (в

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

изменениям;

 административные границы, используемые для разграничения зон

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

на организации, которые имеют один IP-узел или более. Каждая

организация, которая отвечает за соответствующую группу

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

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

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

использовать;

 целесообразно, чтобы клиенты DNS-системы обладали способностью

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

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

этим серверам, находясь вне зоны действия этой “доверенной” группы

серверов;

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

обновление данных или гарантии последовательности процедуры

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

данных допускает прохождение дополнительных данных через

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

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

вследствие сбоев в сети или IP-узле, то тогда обычно доверяют старой

информации, пока продолжаются попытки ее обновить. Общая модель

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

использованием режима “тайм-аута”. Система распределения

информации устанавливает значение “тайм-аута”, а получатель такой

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

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

информации может запретить ее копирование;

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

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

ответ на который может дать только какой-либо другой сервер.

Существуют два общих подхода для решения этой проблемы:

 “рекурсивный” (последовательное обращение), при котором первый

сервер выступает от имени клиента и сам направляет его запросы на

другой сервер;

 “итеративный” (повторное обращение), при котором первый сервер

направляет клиента на другой сервер и разрешает клиенту направить

свой запрос.

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

способ повторного обращения (итеративный) предпочтительнее для

дейтаграммного метода доступа. DNS-система требует применения

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

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

DNS-система предполагает, что все источники данных, содержащиеся в

“мастер-файлах”, “разбросаны” по IP-узлам, которые используют DNS-систему.

Эти мастер-файлы обновляются администраторами локальных систем. Мастер-

файлы представляют собой текстовые файлы, которые “читаются” локальным

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

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

серверам имен через стандартные программы называемые преобразователи IP-

адресов (“resolver”) или DNS-клиенты.

Стандартный формат мастер-файлов обеспечивает возможность их

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

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

организация хочет иметь сегмент/область, но не хочет обслуживать сервер

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

этого текстовый редактор, и передавать их на внешний IP-узел, который

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

сервера имен относительно обратного получения этих файлов для обработки

(загрузки в сервер организации).

Серверы имен и DNS-клиенты, обслуживаемые каждым IP-узлом,

настраиваются администратором локальной системы. Для сервера имен такая

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

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

внешних серверов. Сервер имен использует мастер-файлы или их копии для

загрузки своих зон. Для DNS-клиентов такая настройка включает определение

серверов имен, которые, целесообразно, использовать в качестве первичных

источников данных (информации).

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

перенаправления на другие серверы имен. Она также описывает процедуры

кэширования восстанавливаемых данных и периодического обновления

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

Системные администраторы обеспечивают:

 определение зональных границ;

 обработку мастер-файлов данных;

 обновление мастер-файлов;

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

данных.

DNS-система обеспечивает:

 стандартные форматы информационных ресурсов;

 стандартные методы обращения к базе данных;

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

обновлении ими локальной информации, находящейся во внешних

серверах имен.

1.4. Составные элементы DNS - системы

DNS-система система включает в себя три основных компонента:

a. пространство имен сегментов/областей и записи информационных

ресурсов (Resource Records — RR), которые определяют древовидную

структуру пространства имен и данные, связанные с этими именами. С

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

пространства имен сегментов/областей определяет имя блока

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

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

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

указывает тип востребованного информационного ресурса. Например,

Internet использует некоторые имена своих сегментов/областей для

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

информации направляются IP-адреса Internet-узлов;

b. серверы имен (DNS-серверы) представляют собой программные

комплексы, размещаемые в специализированных серверах, которые

содержат информацию о структуре дерева сегмента/области и блоки

данных. Сервер имен может хранить (обрабатывать) в кэш-памяти

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

сегмента/области, но в целом соответствующий сервер имен владеет

полной информацией о подмножестве пространства имен

сегмента/области и содержит указатели на другие серверы имен, которые

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

части дерева сегмента/области. Серверы имен знают части дерева

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

информацией, и поэтому их называют достоверными источниками

данных (“Authority”) для этих частей пространства имен. Достоверная

информация, с точки зрения организации, распределяется по группам,

называемым “зонами”, а эти зоны могут быть автоматически

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

информационное обслуживание в зоне;

c. DNS-клиенты представляют собой специализированные программные

комплексы (специализированные программные интерфейсы), которые

“извлекают” информацию из серверов имен в ответ на запросы клиентов.

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

имен и использовать информацию этого сервера имен для ответов на

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

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

системной программой (частью операционной системы — ОС), которая

непосредственно доступна для программ пользователя, поэтому нет

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

взаимодействия DNS-клиент программой пользователя.

Эти три компонента приближенно отображаются в три уровня DNS-

системы (три взгляда на DNS-систему):

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

локальному DNS-клиенту с помощью простой процедуры или путем

запуска специализированного системного процесса ОС. Пространство

сегмента/области состоит из одиночного дерева, а пользователь может

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

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

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

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

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

данных;

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

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

обладает локальными копиями некоторых из этих зон. Сервер имен

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

из локальных файлов или внешних серверов имен. Сервер имен обязан

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

клиентов.

В интересах более качественного функционирования, прикладные

программные DNS-модули могут связывать эти функции. Например, DNS-

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

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

имен, и кэш-памяти, управляемой DNS-клиентом.

ПРОСТРАНСТВО ИМЕН СЕГМЕНТОВ/ОБЛАСТЕЙ И ЗАПИСИ

ИНФОРМАЦИОННЫХ

РЕСУРСОВ

2.1. Требования к пространству имен и используемая терминология

Пространство имен сегментов/областей представляет собой древовидную

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

(подмножество) информационных ресурсов (которая может быть и пустой).

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

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

“узел”.

Каждый узел имеет свой маркер, который имеет длину 0…63 октета.

“Узлы-братья” не могут иметь один и тот же маркер, несмотря на то, что один и

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

“братьями”. Одно значение маркера является резервным, и это значение равно

“0” (то есть, маркер нулевой длины), а сам маркер нулевой длины используется

для обозначения корня древовидной структуры.

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

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

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

читаются слева на право, от наиболее частного (самый дальний (нижний) от

корня) к наиболее общему (самый ближний (верхний) к корню).

С точки зрения операционной системы, целесообразно, чтобы

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

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

последовательность битов длиной в один октет, следующую в потоке октетов.

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

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

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

По имеющейся договоренности, DNS-имена могут храниться

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

имеющихся DNS-функций осуществляются на основе способа, при котором

строчные и прописные символы не различаются, учитывая применение ASCII-

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

присвоение узлам имени “А” и имени “а”, то только в том случае, когда эти

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

тогда возможно сохранение прописного/строчного символа. В таком случае

целесообразно, чтобы в дальнейшем была возможность (при необходимости)

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

изменений существующие службы.

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

маркера опускается, а сами маркеры разделяются точками (“.”). Так как полное

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

также будет заканчиваться точкой. Данное свойство используется для

определения различий между:

 последовательностью символов, которая представляет собой полное

DNS-имя (часто называемое “абсолютным”). Например,

“poneria.ISI.EDU.”;

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

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

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

информацию локального сегмента/области (часто называемое

“относительным”). Например, “poneria” используется в сегменте

“ISI.EDU”.

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

источнику, либо к перечню сегментов/областей в качестве списка поиска.

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

интерфейсах (где их представление варьируется от одной прикладной

реализации до другой) и мастер-файлах (где они связаны с одним DNS-именем

источника). Наиболее общее представление использует точку (“.”) корневого

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

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

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

сохранения корректности переписки.

С целью упрощения прикладных процессов, общее количество октетов, с

помощью которых формируется DNS-имя, ограничивается значением 255 (это

общая сумма всех маркерных октетов и собственно маркеров).

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

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

определяющего сегмент/область. Сегмент (область) является субсегментом

(субобластью) другого сегмента (области), если он(а) расположен(а) внутри

последнего(ей). Например, A.B.C.D является субсегментом (субобластью)

B.C.D, C.D, D и “ ”.

2.2. Административное руководство по применению

С точки зрения общей стратегии, техническая спецификация DNS-

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

дерева или правила для выбора маркеров. Ее цель быть максимально общей,

чтобы она могла быть использована при создании произвольных прикладных

служб или систем. В частности, DNS-система была спроектирована таким

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

сетевых границ, DNS-серверов” и т.д. Это сделано не для того, чтобы не

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

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

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

различные части древовидной структуры могли иметь различную семантику

имен. Например, сегмент “IN-ADDR.ARPA” организован сетью и распределяет

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

предназначение — трансляция номеров сетей или IP-узлов в имена и наоборот.

Однако существуют некоторые общие рекомендации, которые

применимы для некоторых “обычных” частей пространства имен,

используемого IP-узлами, почтовыми серверами и т.д. Такие рекомендации

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

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

которые конвертируются из старых таблиц IP-узлов.

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

несколько зон, должны будут иметь такое “ветвление” в своей верхней части,

чтобы в последующей декомпозиции не надо было бы их переименовывать.

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

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

более запретительных вариантов выбора.

2.3. Техническое руководство по применению

Прежде чем DNS-система могла использоваться для хранения

информации об именах в интересах какого-нибудь типа объекта, она должна

удовлетворять следующим двум требованиям (правилам):

 соглашение по отображению между именами объектов и DNS-именами.

Оно определяет порядок доступа к информации об объекте;

 RR-типы и форматы данных для описания объекта.

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

Очень часто, проектировщик обязан учитывать наличие существующих

форматов и предусматривать совместимость различных форматов для их

последующего совместного использования. Для этого может потребоваться

многократное или многоуровневое отображение.

Для IP-узлов, отображение зависит от существующего синтаксиса имен

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

представления DNS-имен, совместно с RR-форматами для описания адресов IP-

узлов и т.д. Это объясняется тем, что в сети необходимо точное однозначное

отображение адресов в имена IP-узлов, и помимо этого также определено

специфическое отображение адресов в сегмент “IN-ADDR.ARPA”

Для почтовых серверов, отображение является немного более сложным.

Обычный почтовый адрес <local-part>@<mail-domain> отображается в DNS-

имя путем конвертации <local-part> (локальной части) в одиночный маркер (не

обращая внимания на наличие точек), и конвертации <mail-domain> (части

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

для DNS-имен (точки указывают на разделы между маркерами), и

последующего соединения этих двух элементов в одно одиночное DNS-имя.