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

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

4.3.2. Получение измененной зоны должно выполняться при помощи запроса AXFR. Команда AXFR должна выдаваться первичному серверу при обнаружении увеличения параметра SERIAL записи RR SOA для данной зоны на первичном сервере.

4.4. Реализация первичного сервера зоны

Если сервер поддерживает функции первичного сервера зоны DNS, при получении запроса AXFR он должен выдать ответы, содержащие все записи RR, относящиеся к зоне, указанной в запросе. Причем первое и последнее сообщения ответа должны содержать данные для верхнего авторитетного узла в зоне.

5.ОПИСАНИЕ СИСТЕМЫ ДОМЕННЫХ ИМЕН

5.1. Структура системы доменных имен

5.1.1. Основные компоненты системы доменных имен.

В DNS входят три основные компоненты:

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

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

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

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

Предполагается, что в доменной системе все данные находятся в контрольных файлах (master files), распределенных по узлам сети, использующим доменную систему. Изменения в данные контрольных файлов заносятся системными администраторами. Контрольные файлы имеют стандартный текстовый формат, поэтому различные узлы могут обмениваться контрольными файлами с использованием любых средств передачи файлов.

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

5.1.2. Основные конфигурации взаимодействия сервера, клиента и разрешающей системы в системе DNS.

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

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

Рисунок. 1. Доступ клиента к пространству доменных имен через рекурсивный сервер имен

Рисунок. 2. Доступ клиента к пространству доменных имен через нерекурсивный сервер имен

5.2. Структура пространства доменных имен

Пространство доменных имен является древовидной структурой. Каждый узел и лист дерева соответствует определенному набору данных о ресурсах. Этот набор данных может быть пустым. Доменная система одинаково использует внутренние узлы и листья дерева, поэтому далее листья называются тоже узлами дерева. Каждому узлу дерева присвоена метка длиной от 0 до 63 символов. Длина метки корневого узла должна быть равна 0.

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

Домен A называют субдоменом другого домена B, если A содержится в домене B.

Кроме разделения на субдомены рассматривают разделение доменов на классы и зоны. Разделение домена на классы осуществляется в соответствии со значением поля CLASS записей RR, в которых хранится информация о домене. Разделение на зоны рассматривается в п. 6.2.3.

Замечание: Необходимо различать понятия "узел доменного дерева" и "узел сети передачи данных". Узел сети передачи данных может иметь несколько сетевых адресов, которым будут соответствовать несколько узлов доменного дерева. Узел сети передачи данных может вообще не иметь доменного имени и соответствующего узла доменного дерева.

5.2.1. Доменные имена

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

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

5.2.1.1. Внутренняя форма представления доменного имени

Каждая метка хранится в виде одного октета длины, за которым следует некоторое количество октетов, содержащих символы метки. Так как каждое доменное имя заканчивается нулевой меткой, обозначающей корень, представление каждого доменного имени заканчивается октетом длины, содержащим 0. Октет длины содержит два старших бита, установленных в 0. Оставшиеся 6 битов содержат значение длины поля символов метки от 0 до 63. Общая длина доменного имени (сумма всех октетов символов и октетов длин) не должна превышать 255 октетов.

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

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

domain-name ::= [ subdomain ] nul-label

subdomain ::= label / (subdomain label)

label ::= length letter [ [ ldh-str ] let-dig ] ; максимальная длина label

; составляет 63 символа

length ::= 2(0bit) len-val

len-val ::= 6(Xbit) ; 6-битное значение длины соответствующей

; метки label

nul-label ::= 8(0bit)

character-string ::= s_length *256(char) ; символьная строка

s_length ::= 8(Xbit) ; длина символьной строки в

; октетах

ldh-str ::= let-dig-hyp / (let-dig-hyp ldh-str)

let-dig-hyp ::= let-dig / "-"

let-dig ::= letter / digit

letter ::= <любая из 52 алфавитных символов кода ASCII

от A до Z и от a до z>

char ::=

digit ::=

Xbit ::=

0bit ::=

unsigned_int32 ::= 32(Xbit) ; 32-разрядное целое без знака

5.2.1.2. Печатная форма представления доменного имени

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

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

domain ::= subdomain / " "

subdomain ::= label / (subdomain "." label)

label ::= letter [ [ ldh-str ] let-dig ] ; максимальная длина label

; составляет 63 символа

ldh-str ::= let-dig-hyp / (let-dig-hyp ldh-str)

let-dig-hyp ::= let-dig / "-"

let-dig ::= letter / digit

letter ::= <любая из 52 алфавитных символов кода ASCII

от A до Z и от a до z>

digit ::=

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

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

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

Псевдоним присваивается узлу с помощью соответствующей записи RR типа CNAME. Запись RR типа CNAME содержит в разделе "владелец" псевдоним владельца, а в разделе RDATA - соответствующее каноническое имя. Если в узле присутствует RR типа CNAME, то не должно быть никаких других данных для этого узла.

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

Если в RR типа CNAME вместо канонического имени указан псевдоним, сервер DNS должен проследить всю цепочку таких RR, пока не будет найдено каноническое имя, либо не будет выявлена ошибка.

5.2.3. Зоны домена

5.2.3.1. Разбиение домена на зоны

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

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

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

- Авторитетные данные для всех узлов данной зоны

- Данные, определяющие верхний узел зоны

- Данные, описывающие делегированные подзоны

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

Все эти данные представлены в виде записей RR. Таким образом зона может быть полностью описана набором RR. Зона может быть перенесена с одного сервера имен на другой путем передачи записей RR либо путем передачи целого контрольного файла.

Записи RR, описывающие верхний узел зоны, разделяются на: записи NR RR, представляющие список всех серверов имен данной зоны, и одну запись SOA RR, описывающую параметры управления зоной.

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

Данные NS RR не являются частью авторитетных данных зоны, так как определяют "разрезы" между узлами, а не узлы (так как не содержат адресной информации). Каждая запись NS RR должна быть идентична верхней записи RR соответствующей подзоны. В отдельной зоне записи NS RR должны располагаться рядом с верхним узлом зоны (они входят в число авторитетных) или на "разрезах" вокруг "дна" зоны (они не входят в число авторитетных), но никогда не должны располагаться посредине зоны.

Так как записи NS RR содержат только имена серверов подзон, но не содержат адресов серверов подзон, зона содержит "клеевые" записи RR (не являющиеся авторитетными), которые являются адресными RR для данных серверов. "Клеевые" RR используются в ссылочном ответе.

5.2.3.2. Распространение изменений зоны

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

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