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

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

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

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

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

двумя любыми смежными узлами. После всех таких “разрезаний” каждая

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

зону. В конечном счете, зона является авторизованной для всех имен в

ассоциированном регионе. (Замечание. “Разрезания” в пространстве имен

могут осуществляться в различных местах в интересах различных

классов, DNS-серверы также могут быть различны.)

Эти правила означают, что каждая зона имеет, по крайней мере, один

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

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

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

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

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

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

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

зоне, либо все узлы были бы в одиночной зоне. Вместо этого, БД разбита на

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

контроль древовидную субструктуру. Так как организация контролирует свою

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

данные в зоне, либо создавая при этом новые элементы древовидной

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

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

управления.

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

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

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

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

технологического обслуживания БД.

3.2.1. Технические вопросы

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

 авторизованные данные для всех узлов внутри зоны;

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

рассматриваться как часть авторизованных данных);

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

вокруг нижней части зоны;

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

субзонах (дословно — “приклеенные” (“glue”) данные).

Все эти данные представляются в форме записей об информационных

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

множества RRs. Все зоны могут быть перераспределяться между DNS-

серверами либо путем перераспределения RRs (за счет доставки нескольких

последовательностей сообщений), либо путем циркулярной FTP-передачи

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

Авторизованные данные в зоне представляют собой просто все RRs,

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

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

подчиненных ей субзонах, которые окружают нижнюю часть зоны.

Хотя с точки зрения логики, RRs, определяющие старший узел зональной

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

зонального управления, эти записи — наиболее важные. Эти RRs бывают двух

типов:

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

в зоне (одна запись на сервер);

 одиночная запись о SOA (начало зоны ответственности), которая

определяет параметры управления.

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

зоны, представляют собой записи о DNS-серверах (“NS RRs”), определяющие

имена серверов в этих субзонах. Так как данные о “разрезаниях” пространства

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

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

такими же, как и соответствующие RRs в старшем узле субзоны. В связи с тем,

что DNS-серверы всегда ассоциируются с границами зон, RRs о DNS-серверах

размещаются только в тех узлах, которые являются старшими узлами в

зональных иерархиях. В данных, которые образуют зону, RRs о DNS-серверах

размещаются в старшем узле зональной иерархии (и являются

авторизованными) и в подчиненных субзонах вокруг нижней части зоны (где

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

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

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

любых субзон. Это означает, что “родительские” зоны обладают полной

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

“дочерним” зонам. RRs о DNS-серверах, которые определяют серверы в

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

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

предоставляют их IP-адреса. В частности, если имя DNS-сервера является его

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

DNS-серверах укажут прямо на этот сервер (то есть укажут IP-адрес сервера) с

целью определения его IP-адреса, а потом потребуется контактировать с этим

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

получить. Для преодоления этой проблемы, в зоне имеются добавочные RRs,

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

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

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

в качестве отдельного блока ответного сообщения.

3.2.2. Административные вопросы

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

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

соответствующей “родительской” зоны и получение согласия от ее владельцев

на передачу части их управленческих функций. Хотя не существует каких-либо

ограничений на то, в каком месте древовидной структуры DNS-системы может

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

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

высшего уровня иерархии, и зоны среднего уровня иерархии, которые

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

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

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

факультетов и школ.

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

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

сервера. (Замечание. Не существует требования на то, чтобы DNS-серверы

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

этом сегменте/области.) Во многих случаях, зона будет более доступной для

открытого Internet-сообщества, если ее прикладные программные модули

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

модулей только в физических средствах, контролируемых той же организацией,

которая управляет зоной. Например, в существующей DNS-системе один из

DNS-серверов в интересах Великобритании (UK-регион/область) расположен в

США. Это позволяет американским IP-узлам получать информацию без

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

магистрального канала.

И последним шагом является передача в “родительскую” зону записей о

DNS-серверах “дочерней” зоны и записей о добавочных данных, которые

необходимы для более эффективного делегированного управления.

Администраторы обеих зоны (“родительской” и “дочерней”) должны

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

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

последовательными и неизменными.

3.3. Вопросы функционирования DNS -сервера

3.3.1. Запросы и ответы на них

Главной функцией DNS-серверов является формирование ответов на

стандартные вопросы. Запросы и ответы на них размещаются в стандартных

сообщениях, формат которых представлен в RFC-1035. Запросы содержат

блоки (элементы) “QTYPE”, “QCLASS” и “QNAME”, которые определяют

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

Способ формирования DNS-сервером ответов на запросы зависит от

режима его функционирования, то есть, либо DNS-сервер функционирует в

“рекурсивном” режиме, либо нет:

 простейшим режимом функционирования для сервера является

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

для этого только локальную информацию: ответ включает, либо

сообщение об ошибке, либо собственно ответ на вопрос, либо указатель

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

Все DNS-серверы должны функционировать в нерекурсивном режиме;

 простейшим режимом функционирования для пользователя является

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

DNS-клиента и его ответ включает, либо сообщение об ошибке, либо

собственно ответ на вопрос, и никогда не будет включать указатели

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

Этот вид обслуживания является необязательным (дополнительным) для

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

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

Рекурсивный режим обслуживания наиболее выгоден в следующих

ситуациях, то есть когда имеет место:

 относительно простая (с функциональной точки зрения) запрашивающая

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

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

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

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

который может выступать в качестве промежуточного;

 сеть, в которой наиболее предпочтительнее иметь единую кэш-память,

чем иметь выделенную кэш-память для каждого пользователя.

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

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

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

последующих запросах.

Применение рекурсивного режима обслуживания ограничивается только

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

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

использования двух битов в сообщениях-запросах и сообщениях-ответах:

 бит “RA” (“recursion available” — рекурсия допустима) устанавливается

или “обнуляется” DNS-сервером во всех ответных сообщениях. Если этот

бит имеет значение “1”, то это означает, что DNS-сервер предрасположен

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

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

такого режима обслуживания. Это означает, что бит “RA” указал на

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

применения;

 бит “RD” (“recursion desired” — рекурсия желательна) содержится в

сообщениях-запросах. Этот бит показывает, что запрашивающая сторона

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

запроса. Пользователи могут запросить рекурсивное обслуживание у

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

согласия на такое обслуживание только от тех DNS-серверов, которые

заранее передали бит “RA” со значением “1”, либо от DNS-серверов,

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

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

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

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

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

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

“RA” и “RD”, которые установлены в “1”. (Замечание. DNS-сервер никогда

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

последний не был затребован с помощью бита “RD”, так как это может

привести к сбоям в работе DNS-серверов и их БД.)

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

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

запрос:

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

содержать одну или несколько записей, включающих CNAME, которые

определяют псевдонимы, встретившиеся при формировании ответа;

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

существует. Оно может включать записи, включающие CNAME, которые

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

для DNS-имени, которое в настоящее время не существует;

 индикация врéменной ошибки.

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

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

на поступивший запрос:

 “ошибочное авторизованное имя”, указывающее на то, что такое DNS-

имя не существует;

 индикация врéменной ошибки;

 некая комбинация, состоящая из:

a. записей, которые прямо отвечают на вопрос, и указания о том, что эта

информация либо поступила из зоны, либо является результатом кэш-

обработки;

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

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

передавшего ответ;

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

для запрашивающей стороны.

3.3.2. Алгоритм

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

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

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

Следующий далее алгоритм, предполагает, что RRs структурированы по

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

для кэш-памяти:

 установка значения “1” или “0” бита “RA” в ответном сообщении, в

зависимости от предрасположенности DNS-сервера к обеспечению

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

режим обслуживания допустим и затребован с помощью бита “RD” со

значением “1” в запросе, то тогда необходимо перейти на -итерацию, а в

противном случае — на -итерацию;

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

“предком” для указанного в запросе “QNAME”. Если такая зона найдена,

то тогда необходимо перейти на -итерацию, а в противном случае — на

-итерацию;

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

зоне. Процедура сравнения может завершаться в следующих случаях:

a. если всё значение “QNAME” совпало, то это означает, что узел найден.

Если данные в узле относятся к типу “CNAME”, а “QTYPE” не

совпадает с “CNAME”, то тогда запись “CNAME” копируется в блок

“Ответ” ответного сообщения, “QNAME” изменяется на каноническое

имя в записи “CNAME”, и после чего необходимо перейти назад на -

итерацию. В противном случае, в блок “Ответ” ответного сообщения

копируются все записи, которые совпали с “QTYPE”, и после чего

необходимо перейти назад на -итерацию;

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

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

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

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

зоны. В блок “Авторизация” ответного сообщения копируются записи

о DNS-серверах в субзоне. Размещение в блоке “Дополнение” каких бы

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

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

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

-итерацию;

c. если с некоторым маркером невозможно провести процедуру

сравнения (то есть соответствующий маркер отсутствует), то тогда

необходимо проверить наличие маркера с символом замещения “*”.

Если маркер с символом замещения “*” отсутствует, необходимо

проверить, является ли искомое имя оригинальным “QNAME”,

содержащимся в запросе, или имеющееся имя последовало из

“CNAME”. Если имя является оригинальным, то тогда в ответе

указывается “ошибочное авторизованное имя” и обработка

завершается. В противном случае, обработка завершается без каких-

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

“*” имеет место, то тогда все записи, имеющиеся в этом узле,

сравниваются с “QTYPE”. Если некоторые записи совпали, то они

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

имя владельца записи, находящееся в “QNAME”, а не имя узла, в

котором имеет место маркер с символом замещения “*”. Далее

необходимо перейти на -итерацию;

 начало процедуры сравнения в кэш-памяти. Если запись с нужным

“QNAME” найдена в кэш-памяти, то тогда все записи, прикрепленные к

ней, которые совпали с “QTYPE”, копируются в блок “Ответ” ответного

сообщения. Если среди авторизованной информации не было никаких

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

запись и размещается в блок “Авторизация”. Далее необходимо перейти

на -итерацию;

 применение локального DNS-клиента или копии его алгоритма для ответа

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

записи с “CNAME”, в блоке “Ответ” ответного сообщения;

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

записи, которые могут быть полезны, в блок “Дополнение” сообщения

запроса. Процедура обработки завершается.

3.3.3. Записи с символом замещения

В рассмотренном выше алгоритме была представлена специальная

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

начинающихся с маркера с символом замещения “*”. Такие записи носят

название запись с символом замещения (“wildcards”). Записи с символом

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

RRs. При выполнении необходимых условий DNS-сервер формирует RRs с

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

из ЗСЗ.

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

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

из Internet в другие почтовые системы. Основная идея состоит в том, что в

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

считается заранее существующим (с заранее известными свойствами), если

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

(Замечание. Используемый здесь термин “зона”, вместо термина

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

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

такой же терминологии за счет применения подобных “недоразумений”.)

Содержание ЗСЗ подчиняется тем же правилам и форматам, которые

стандартизированы для RRs. ЗСЗ в зоне содержат имя ее владельца, чтобы

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

подвергаться процедуре сравнения. Имя владельца в ЗСЗ имеет следующую

форму “*.<anydomain>”, где “<anydomain>” — имя любого сегмента/области.

Маркер “<anydomain>” не должен содержать каких-либо других символов

замещения “*”, и он должен размещаться в авторизованных данных зоны. ЗСЗ,

как правило, применяется для “потомков” “<anydomain>”, но не для

обозначения сегмента/области. С другой точки зрения, это означает то, что

маркер с символом замещения “*” всегда сравнивается, по крайней мере, с

одним полным маркером, а иногда и с несколькими, но всегда с полными

маркерами.

ЗСЗ не применяются в следующих случаях:

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

последствии такой запрос будет уничтожен в режиме “по умолчанию”;

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

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

запрашиваемым именем существует. Например, если ЗСЗ содержит имя

владельца “*.Х”, и зона также включает записи, прикрепленные к “В.Х”,

то тогда ЗСЗ будут применяться в запросах для имени “Z.X” (полагая, что

не существует точной информации о “Z.X”), но никогда в “B.X”, “A.B.X”

или “X”.

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

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

тестирования ЗСЗ в авторизованной зоне. Такой тест-запрос предназначен

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

владельца зоны, в котором присутствует маркер с символом “*”. Результат

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

(Замечание. Содержание ЗСЗ не изменяется, когда они

используются для синтеза RRs.)

Для иллюстрации использования ЗСЗ предположим, что имеет место

крупная компания со своей (не TCP/IP) сетью, которая желает сформировать

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

имеет название “X.COM”, а реальный сервер, функционирующий как TCP/IP-

шлюз, имеет название “A.X.COM”, то тогда следующие записи будут внесены в

БД зоны:

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

Это повлечет за собой “МХ”-запрос (то есть запрос имени почтового

сервера) для любого DNS-имени, заканчивающегося на “X.COM”, в результате

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

“A.X.COM”. В данном примере требуются две ЗСЗ, так как значение символа

замены в “*.X.COM” ограничивается в древовидной субструктуре “A.X.COM”,

за счет очевидности данных в интересах “A.X.COM”. Также необходимы

точные данные о “МХ” в “X.COM” и “A.X.COM”, и ни одна из

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

“XX.COM”.

3.3.4. Хранение отрицательных ответов в кэш-памяти

( дополнительная функция )

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

серверам передавать, а DNS-клиентам хранить в кэш-памяти, отрицательные

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

сообщение с меткой TTL, в котором также укажет на ошибку в имени, после

этого DNS-клиент, получив такую информацию, может предположить, что имя

не существует в течении TTL периода, не обращаясь при этом к

авторизованным данным. Таким же образом, DNS-клиент может сформировать

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

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

которые не представлены.

Такое свойство может быть весьма важным в системе, которая

применяет систему именования символов/знаков (но не буквенно-цифровые

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

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

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

именах.

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

“SOA” в блок “Дополнение” ответного сообщения, когда последнее является

авторизованным. Запись “SOA” должна быть из той зоны, которая была

источником авторизованных данных, содержащихся в блоке “Ответ”

(“Answer”) или в блоке, указывающем на ошибку в имени (если таковая имела

место). В записи “SOA” имеется специальное поле “Minimum”, содержащее

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

храниться в кэш-памяти.

(Замечание. В некоторых ситуациях, блок “Ответ” может содержать

несколько имен владельца зоны. Если последнее имеет место, то тогда

механизм использования записи “SOA” целесообразно применять только

для тех данных, которые сравниваются с “QNAME”, то есть в данном

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

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

добавлять записи “SOA” в свои неавторизованные сообщения-ответы в рамках

блока “Дополнение” (“Additional”), или никогда не пытались выводить

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

ответе. Для этого существует несколько причин, среди которых:

 объем информации, хранящейся в кэш-памяти, как правило, не

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

именами;

 записи с “SOA” могут проходить процедуру кэш-обработки, благодаря

прямым SOA-запросам;