RFC-1035. Система именования сегментов/областей. Реализация и спецификация (DNS). Ноябрь 1987 года (категория: стандарт)

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

3 F

O O

1 1 20

1 1 26

Рис.35. Пример компрессии имен в DNS-сообщении

3.2. Протоколы транспортного уровня

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

форме дейтаграмм (без установления соединения) или в форме

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

установлением соединения). Несмотря на то, что виртуальные соединения

могут использоваться в интересах любого аспекта функционирования DNS-

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

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

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

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

доставку сообщений.

В Internet для DNS-системы стандартом определены два порта:

 ТСР-порт (RFC-793) — 53;

 UDP-порт (RFC-786) — 53.

3.2.1. UDP- протокол

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

53 UDP-порт DNS-сервера.

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

превышать длину 512 байтов (не считая IP- и UDP-заголовки). Более длинные

DNS-сообщения разрезаются, а в заголовке бит “ТС” устанавливается в

единицу.

UDP-протокол не используется при внутризоновом информационном

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

в Internet. Запросы, которые передаются с помощью UDP-протокола, могут

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

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

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

вызванным либо функционированием сети или обработкой в DNS-серверах,

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

DNS-сообщений.

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

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

от нужд DNS-клиента. Однако в этом вопросе следует придерживаться

следующих рекомендаций:

 DNS-клиенту целесообразно задействовать другие серверы или адреса

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

сервера;

 если это возможно, то временной интервал режима “тайм-аута” должен

основываться на предварительном статистическом анализе. Слишком

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

если сеть охватывает большое количество узлов и пользователей. В

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

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

2…5 секунд.

3.2.2. TCP- протокол

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

53 TCP-порт DNS-сервера. К DNS-сообщению дополняется 2-байтовым полем

“Length”, которое отражает длину сообщения, за исключением самого

добавленного поля. Это поле “Length” помогает протоколам нижних уровней

Internet-архитектуры осуществлять процедуру “сборки” всего сообщения перед

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

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

соединением:

 сервер не должен останавливать другие процессы во время ожидания

данных, передаваемых в соответствии с ТСР-протоколом;

 сервер должен обслуживать несколько соединений одновременно;

 сервер должен предполагать, что DNS-клиент будет инициировать

процедуру разъединения, и должен воздерживаться от разъединения до

тех пор, пока все поступившие от DNS-клиента запросы не будут

удовлетворены;

 если серверу необходимо закрыть “бездействующее” соединение для

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

соединение не перейдет в “холостой” режим, то есть примерно в

течение двух минут. В частности, сервер должен разрешить передачу

последовательности запросов “SOA” и “AXFR” (с которых начинается

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

соединению. Так как в любом случае сервер не сможет ответить на

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

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

нормального поэтапного разъединения.

IV.

МАСТЕР

ФАЙЛЫ

Мастер-файлы представляют собой текстовые файлы, которые содержат

RR-записи в текстовой форме. Так как содержание зоны может быть

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

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

перечня компонентов, хранящихся в кэш-памяти.

4.1. Формат мастер-файлов

Формат таких файлов представляет собой последовательность записей

(строк). Эти записи являются преимущественно линейно-ориентированными

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

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

того, текстовые константы могут включать символ “CRLF” (“перевод каретки

— новая строка”), то есть внутри текста. Любая комбинация символов

“табуляция” и “пробел” выступает в роли разделителя между элементами,

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

может размещаться комментарий. Комментарий начинается после

разделительного символа “;” (точка с запятой).

Далее приводится пример записи в мастер-файле:

<blank> [<comment>]

$ORIGIN <domain-name> [<comment>]

$INCLUDE <file-name> [<domain-name>] [<comment>]

<domain-name> <rr> [<comment>]

<blank> <rr> [<comment>].

Пустые строки (<blank>), с комментариями или без, допускаются в любых

местах мастер-файла.

В мастер-файлах различают две управляющие строки:

 “$ORIGIN” (источник) следует перед DNS-именем, и

переустанавливает все DNS-имена соответствующих владельцев в одно

имя установленного владельца;

 “$INCLUDE” (вставка) вставляет файл с именем в текущий файл, и

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

для включенного файла. Эта строка также может иметь комментарий.

(Замечание. Строка “$INCLUDE” никогда не изменяет

соответствующий источник “родительского файла”, не обращая

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

источник внутри включенного файла.)

Последние две строки представляют собой RR-записи. Если строка для

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

последнему установленному владельцу. Если же строка для RR-записи

начинается с <domain-name> (с DNS-имени), то тогда имя владельца

переустановлено.

Содержание записи <rr> может иметь одну из следующих форм:

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

RR-запись начинается с дополнительного поля “TTL” и поля “CLASS”, за

которыми следует поле “TYPE” и поле “RDATA”, которое соответствует типу и

классу записи. Поля “CLASS” и “TYPE” используют стандартную мнемонику,

поле “TTL” представляет собой целое десятичное число. Пропущенные

значения в полях “CLASS” и “TTL” по умолчанию заполняются последними

установленными в явном виде величинами. Так как тип и класс никак

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

уникальной. (Замечание. Такой порядок отличается от порядка, который

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

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

обработку записей и корректировку величин по умолчанию.)

DNS-имена (<domain-name>) занимают большую часть данных в мастер-

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

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

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

DNS-имен. DNS-имена, которые заканчиваются точкой, называются

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

которые не заканчиваются точкой, называются относительными. Реальное

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

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

“$ORIGIN” и “$INCLUDE”, или его можно представить как аргумент для

мастер-файла, загружающего программу. Относительное имя считается

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

Последовательность символов (<character-string>) может быть

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

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

пробелов (табуляций);

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

кавычек (“) и заканчивается закрывающими кавычками (”). Кавычки

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

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

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

дробями “\” (back slash).

Так как эти файлы являются текстовыми файлами, существует несколько

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

произвольных данных, а именно:

 “\отсутствие символов\” — из корневого имени;

 “@” — свободная константа, которая используется для обозначения

соответствующего имени источника записи;

 “\Х” — где “Х” любой символ кроме цифр (0…9), используется для

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

прямому назначению не используется. Например, “\.” может

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

 “\DDD” — где каждый символ “D” является цифрой, представляет собой

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

символами “DDD”. Предполагается, что итоговый октет будет

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

специального средства;

 “( )” — обычные круглые скобки используются для групповых данных,

которые выходят за границу строки. Фактически, границы строк не

могут быть определены внутри круглых скобок;

 “;” — точка с запятой используется для обозначения начала

комментария. В данном случае указатель строки игнорируется.

4.2. Использование мастер-файлов для определения зон

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

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

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

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

Например, допустим, что RR-запись определяет процедуру перенаправления

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

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

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

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

DNS-сервере).

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

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

синтаксических ошибок:

 все RR-записи в файле должны иметь один и тот же класс;

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

“SOA”;

 если представлена процедура перенаправления запросов и для этого

необходимы добавочные (“glue”) данные, то тогда последние должны

быть представлены;

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

зоне, должна быть указана в форме добавочных (“glue”) данных, что

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

ошибки в имени источника записи или ей подобной.

4.3. Пример мастер - файла

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

определения зоны “ISI.EDU” и который загружается вместе с именем владельца

этой зоны (источника записи):

@ IN SOA VENERA Action\.domains (

20 ; SERIAL

7200 ; REFRESH

600 ; RETRY

3600000 ; EXPIRE

60) ; MINIMUM

NS A.ISI.EDU.

NS VENERA

NS VAXA

MX 10 VENERA

MX 20 VAXA

A A 26.2.0.103

VENERA A 10.1.0.52

A 128.9.0.32

VAXA A 10.2.0.27

A 128.9.0.33

$INCLUDE <SUBSYS> ISI-MAILBOXES.TXT

Файл “<SUBSYS> ISI-MAILBOXES.TXT” представляет собой:

MOE MB A.ISI.EDU.

LARRY MB A.ISI.EDU.

CURLEY MB A.ISI.EDU.

STOOGES MG MOE

MG LARRY

MG CURLEY

(Замечание. Символ обратная дробь “\” (back slash) в записи “SOA”

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

“Action.domains@E.ISI.EDU”.)

DNS

СЕРВЕРЫ

5.1. Архитектура

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

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

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

будет иметь общую с DNS-клиентом БД.

5.1.1. Управление

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

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

отдельных прикладных задач, одновременно решаемых операционной

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

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

должен блокировать обслуживание UDP-запросов в период ожидания TCP-

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

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

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

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

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

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

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

внутри корпоративного процесса обновления данных в зоне в своей БД.

5.1.2. База данных

Хотя программные реализации DNS-сервера “свободны” с точки зрения

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

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

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

DNS-сервера, и “указатель” для данной структуры зональных данных.

Главное предназначение этой структуры — поиск ближайшей

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

поступающих стандартных запросов;

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

DNS-серверу;

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

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

классами).

Все эти структуры данных могут иметь древовидную иерархию, а сами

данные относятся к находящимся в различных частях узлам. Каталог данных

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

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

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

разработчик должен:

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

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

основе безрегистрового способа проверки;

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

очень большим коэффициентом ветвления (100…1000 или более), но

явное большинство узлов будет иметь низкий коэффициентом

ветвления (0…1).

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

каждого узла в составе двух элементов:

 собственно маркер в стандартном представлении, в котором все ASCII-

символы имеют один регистр;

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

регистрами.

Различие коэффициентов ветвления может быть регулируемым на основе

применения:

 простого связного перечня в узле пока коэффициент ветвления не

превышает некоторого порогового значения;

 и перечня, переходящего в смешанную структуру, когда коэффициент

ветвления превышает пороговое значение.

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

элементов древовидной иерархии, должна гарантировать, что смешанные

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

безрегистрового способа проверки, приятого в DNS-системе.

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

следующими причинами:

 структура “каталог” может быть почти статичной, требующей

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

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

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

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

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

перемещать зону, а именно, путем изменения указателя в каталоге.

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

по завершении создания встроить ее в БД путем простого добавления

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

будут одновременно использовать старую и новую информацию;

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

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

приоритетны (имеют большую значимость) по сравнению с

кэшируемыми данными;

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

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

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

“хорошие зоны”;

 так как кэшируемые данные являются наиболее часто обновляемыми

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

перезагрузок системы. Они также могут стать чрезмерно большими из-

за просроченных данных в RR-записях. В каждом случае, это может

быть легко определено без какого-либо распределения зональных

данных.

Главным аспектом проектирования БД является выбор структуры,

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

сбоями в собственной системе. Информация о состоянии системы, которую

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

системе, включает структуру данных типа “каталог” (включая информацию о

состояние обновления данных в каждой зоне) и собственные зональные

данные.

5.1.3. Время

Время TTL и время обновления данных определяется 32-битовыми

значениями времени в секундах. С точки зрения внутреннего содержания БД,

счетчики времени обновления информации и TTL для кэшируемых данных

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

зоне “задерживаются” в течение постоянного интервала TTL.

Прикладным программным модулям рекомендовано хранить временные

интервалы двумя способами:

 как относительное возрастающее время;

 как абсолютное время.

Первый способ позволяет использовать положительные 32-битовые

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

записей. RR-записи в зонах используют относительное время. Счетчики

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

абсолютное время. Абсолютные значения времени применяются с учетом

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

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

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

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

5.2. Обработка стандартных запросов

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

стандарте RFC 1034.

Когда обрабатываются запросы (“wildcards”) с символом замещения (“*”)

“QCLASS=*” или другие запросы с несколькими классами записей, то тогда

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

DNS-сервер может гарантировать, что ответ относится ко всем классам RR-

записей.

Когда формируется комбинированный ответ, RR-записи, которые

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

поле “Answer” или в поле “Authority”, могут не размещаться в поле

“Additional”.

Когда сообщение-ответ слишком большое и требует своего сокращения,

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

этого размещаться в дейтаграмме. Таким образом, даже если в поле “Authority”

отсутствуют некоторые данные, поле “Answer” должно быть гарантировано с

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

Значение “Minimum” в субполе “SOA” должно использоваться в качестве

минимального временного интервала TTL хранения данных, которые

распределяются в зоне. Это значение должно копироваться в период записи

информации в сообщение-ответ. В дальнейшем это позволит перспективным

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

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

5.3. Обработка данных при обновлении и перезагрузке зоны

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

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

файле обнаружены синтаксические ошибки. То же самое относится и к

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

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

зону.

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

запроса “AXFR”, а в этот период сформирована новая версия зоны, то тогда

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

возможно. В любом случае, передача части одной версии и части другой версии

не допустима. Если завершение невозможно, то тогда необходимо

переустановить виртуальное соединение.

5.4. Встречные запросы ( дополнительная функция )

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

функцией DNS-системы. От DNS-серверов не требуется реализация этой