Перевод RFC 3403

Network Working Group Request for Comments: 3403 Obsoletes: 2915, 2168 Category: Standards Track

M. Mealling

VeriSign

October 2002

Система DDDS. Часть 3 – База данных DNS

Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database

Статус документа

Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Авторские права

Тезисы

Этот документ описывает Базу данных DDDS¹, использующую систему DNS² в качестве распределенной базы Правил. Ключами являются доменные имена и Правила представляются с использованием записей NAPTR RR³.

Поскольку этот документ отменяет действие RFC 2915, он является официальной спецификацией для записей NAPTR в DNS. Документ также является частью серии, полностью указанной в документе "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Оглавление

1. Введение ................................................................................................................................................................................ ...... .................... 1

2. Терминология ............................................................................................................................................................................... ...... ........... 2

3. Спецификация Базы данных DDDS ........................................................................................................................................................ ..2...

4. Формат NAPTR RR ........................................................................................................................................................ ..... ........................... 3

4.1 Формат пакета ................................................................................................................................................................................... ....3...

4.2 Обработка дополнительной информации ..................................................................................................................... .................... 4

4.2.1 Обработка раздела Additional серверами DNS ...................................................................................................... ...... ............. 4

4.2.2 Обработка раздела Additional Information преобразователями и приложениями ........................................... ................... 4

4.3 Формат Master-файла ..................................................................................................................................................................... ....4...

5. Спецификация Приложения ................................................................................................................................................................. ...... 4.

6. Примеры .......................................................................................................................................................................................... ............. 4

6.1 Пример URN ........................................................................................................................................................................................ 4...

6.2 Пример E164 ........................................................................................................................................................................................ 5...

7. Совет администраторам DNS ........................................................................................................................................................ .... .......... 5

8. Примечания .................................................................................................................................................................................................. 5...

9. Согласование с IANA ........................................................................................................................................................ ....... ...................... 5

10. Вопросы безопасности ................................................................................................................................................. .............................. 5

Литература ..................................................................................................................................................................................................... ..5...

Адрес автора ........................................................................................................................................................................................... ......... 6

Полное заявление авторский прав ................................................................................................................................................. ................ 6

1. Введение

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

Этот документ описывает способ, при котором используется система DNS в качестве хранилища Правил, обеспечивающих функционирование Приложения DDDS. Документ не задает какого-либо конкретного приложения или сценария использования. Вся серия документов описана в "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

¹Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий.

²Domain Name System – система доменных имен

³Naming Authority Pointer Resource Record – запись для указателя на уполномоченный сервер именования.

rfc.com.ru

Перевод RFC 3403

Описанная здесь запись DNS NAPTR была изначально предложена рабочей группой URN в качестве способа представления наборов правил в DNS, позволяющих разобрать делегированную часть URI⁴ таким образом, чтобы она могла быть изменена и ределегирована с течением времени. В результате получились записи RR⁵, включающие регулярные выражения, которые используются клиентскими программами для преобразования строк в доменные имена.

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

Со временем процесс был обобщен для других Приложений и Баз данных о Правилах. В этом документе определена База данных о Правилах без задания какого-либо Приложения, поскольку может существовать множество Приложений, способных использовать эту Базу данных о Правилах.

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно

(OPTIONAL) в данном документе интерпретируются в соответствии с [6].

Все прочие термины, особенно выделенные шрифтом, заимствованы из [3].

3. Спецификация Базы данных DDDS

General Description - общее описание

Эта база данных использует систему DNS, описанную в [8] и [7].

Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 - любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX⁶, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX⁷, поскольку это приведет к потере выражениями для замены их универсальности в применении.

Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL⁸. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется м нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма.

Key Format - формат ключей

Ключ представляет собой корректно сформированное доменное имя DNS.

Lookup Request - поисковый запрос

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

Lookup Response - отклик при поиске

Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4.

Rule Insertion Procedure процедура вставки правил

Правила вставляются путем добавления новых записей в соответствующую зону DNS. Если Правило производит Ключ, который существует в конкретной зоне, тогда только объект, имеющий административный контроль над этой зоной, может задавать Правило, связанное с таким Ключом.

Collision Avoidance - предотвращение конфликтов

В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов.

♦ Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM - в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием⁹, следует использовать второй метод.

♦ Создание регулярного выражения, содержащего часть строки AUS¹⁰, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу "+", который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.

⁴Uniform Resource Identifiers – однотипные идентификаторы ресурсов.

⁵Resource Record – запись о ресурсах.

⁶POSIX Extended Regular Expression

⁷POSIX locale

⁸Time To Live

⁹В оригинале “upstream delegation” - передача полномочий вверх по иерархии. Прим. перев.

¹⁰Application Unique String – уникальная строка приложения

rfc.com.ru 2 rfc.com.ru

Перевод RFC 3403

♦ Если два приложения используют различные значения Flags или Services, тогда записи другого Приложения можно игнорировать, поскольку они не будут соответствовать значению Services/Flags.

4. Формат NAPTR RR 4.1 Формат пакета

Формат пакетов NAPTR RR показан на рисунке. Код типа DNS для NAPTR имеет значение 35.

Определения character-string> (строка символов) и <domain-name> (доменное имя) приведены в RFC 1035 [7].

ORDER

16-битовое целое число без знака, задающее порядок, в котором должны обрабатываться записи NAPTR для точного представления упорядоченного списка Правил. Упорядочивание идет от меньших значений к большим. Если две записи имеют одинаковое значение порядка,


		1	1	1	1	1	1
0 1 2 3	4	5 6 7 8 9 0	1	2	3	4	5
+--+--+--+--+-\|	-+-	-+--+--+--+--+--+-ORDER	-+-	-+-	-+-	-+-	-+ \|
+--+--+--+--+-\|	-+-	-+--+--+--+--+--+-PREFERENCE	-+-	-+-	-+-	-+-	-+ \|
+--+--+--+--+-	-+-	-+--+--+--+--+--+-	-+-	-+-	-+-	-+-	-+
/		FLAGS					/
+--+--+--+--+-	-+-	-+--+--+--+--+--+-	-+-	-+-	-+-	-+-	-+
/		SERVICES					/
+--+--+--+--+-	-+-	-+--+--+--+--+--+-	-+-	-+-	-+-	-+-	-+
/		REGEXP					/
+--+--+--+--+-	-+-	-+--+--+--+--+--+-	-+-	-+-	-+-	-+-	-+
/		REPLACEMENT					/
/							/
+--+--+--+--+-	-+-	-+--+--+--+--+--+-	-+-	-+-	-+-	-+-	-+

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

PREFERENCE

Хотя это поле и носит название “предпочтение” в соответствии с принятой в DNS терминологией, в Алгоритме DDDS оно является эквивалентом значения Priority. Это 16-битовое целое число без знака, которое задает порядок, в котором следует обрабатывать записи NAPTR с одинаковыми значениями поля Order (младшие номера обрабатываются раньше старших). Это похоже на поле Preference в записи MX и используется так, чтобы администратор домена мог направить клиентов на более подходящие хосты или менее отягощенные протоколы. Клиент может обращаться к записям с более высокими значениями поля Preference, если у клиента есть достаточные основания для этого (например, отсутствие поддержки некоторых протоколов или служб).

Важное различие между полями Order и Preference заключается в том, что после того, как найдено соответствие, для клиента недопустимо обращаться к записям с другими значениями поля Order, но можно обрабатывать записи с одинаковыми значениями Order и различными значениями Preferences. Единственное исключение из этого правила указано в Примечании к спецификации алгоритма DDDS по части разрешения клиенту использовать более сложное определение сервиса между п. 3 и п. 4 в алгоритме. Значение Preference используется для обозначения более высокого качества сервиса в правилах, которые рассматриваются как одинаковые с точки зрения передачи полномочий, но не с точки зрения распределения нагрузки.

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

FLAGS

Строка символов (<character-string>), содержащая флаги для контроля деталей перезаписи и интерпретации полей записи. Флаги представляют собой одиночные буквы от A до Z или цифры от 0 до 9. регистр букв во внимание не принимается. Поле флагов может быть пустым.

Приложение само задает, как оно использует эту Базу данных для определения флагов в этом поле. Приложение должно определить, какие из флагов трактуются как завершающие.

SERVICES

Строка символов (<character-string>), задающая Параметры сервиса (Service Parameters), применимые к данному пути передачи полномочий. Значения этого поля определяются спецификацией Приложения.

REGEXP

Строка символов (<character-string>), содержащая выражение для замены, которое применяется к исходной строке, сохраняемой клиентом для конструирования следующего искомого доменного имени. Синтаксис этого поля описан в спецификации Алгоритма DDDS.

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

REPLACEMENT

Строка <domain-name>, которая является следующим доменным именем для запроса в зависимости от возможных значений поля флагов. Это поле используется в тех случаях, когда регулярное выражение представляет собой простую операцию замены. Любое значение в этом поле должно быть полным доменным именем. Сокращение имен для этого поля не применяется.

Это поле вместе с полем REGEXP создают Выражение для замены¹¹ в Алгоритме DDDS. Существование этого поля обусловлено историческими причинами, связанными с возможностью сокращения имен в DNS. Упомянутые поля являются взаимоисключающими. Если возвращена запись, имеющая значения для обоих полей, это рассматривается как ошибка и следует игнорировать результат или возвращать сообщение об ошибке.

¹¹Substitution Expression

rfc.com.ru 3 rfc.com.ru

Перевод RFC 3403

4.2 Обработка дополнительной информации

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

4.2.1 Обработка раздела Additional Information серверами DNS

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

4.2.2 Обработка раздела Additional Information преобразователями и приложениями

Приложения могут проверять раздел Additional Information на предмет наличия имеющих отношение к делу записей, но для Приложений недопустимо требовать наличия каких-либо записей в разделе Additional Information любого отклика DNS для обеспечения возможности работы клиентов. Все Приложения должны быть способны обрабатывать отклики от серверов имен, которые никогда не заполняют в откликах раздел Additional Information.

4.3 Формат Master-файла

Формат master-файла соответствует стандартным правилам RFC 1035. Поля Order и Preference, будучи 16-битовыми целыми числами без знака, могут принимать значения от 0 до 65535. Поля Flags, Services и Regexp являются заключенными в кавычки строками (<character-string>). Поскольку поле Regexp может содержать множество символов обратной дробной черты ((backslash), это поле следует трактовать с осторожностью. Работа с регулярными выражениями рассмотрена в главе 7.

5. Спецификация Приложения

Эта База данных DDDS применима для любых приложений, использующих алгоритм DDDS. В дополнение к элементам, требуемым для спецификации Приложения DDDS, приложения, желающие использовать эту базу данных, должны определить перечисленные ниже значения.

♦ К какому домену относится Ключ, создаваемый правилом First Well Known Rule. Каждое приложение должно обеспечивать гарантию того, что его правила не будут конфликтовать с правилами, используемыми другими приложениями, которые работают в этой же Базой данных. Например, приложение foo может задать, что все его ключи, создаваемые первым общеизвестным правилом будут относиться к зоне foo.net.

♦ Какие значения допустимы в полях Services и Protocols.

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

6. Примеры 6.1 Пример URN

Записи NAPTR изначально создавались для использования с сервисом URN RDS¹² [15]. В этом примере рассматривается, как конкретное имя URN будет использовать запись NAPTR для поиска преобразователя, который может ответить на вопрос о URN. Спецификация этого Приложения приведена в документе [2].

Рассмотрим пространство имен a URN, основанное на MIME Content-Id (гипотетическое пространство). URN может иметь вид:

urn:cid:199606121851.l@bar.example.com

Первое общеизвестное правило Приложения служит для извлечения символов между первым и вторым двоеточием. В нашем примере это будет cid. Приложение также задает, что для построения корректного Ключа в конце результата работы First Well Known Rule следует добавить строку urn.arpa. Окончательным результатом тогда будет служить cid.urn.arpa. Далее клиент запрашивает в DNS записи NAPTR для доменного имени cid.urn.arpa. Результатом будет единственная запись:

cid. urn.arpa.

;; order pref flags service regexp replacement

IN NAPTR 100 10 ..........!^Aurn:cid:.+@( [^Л\.]+\.) (.*)$!\2!i"

Поскольку запись является единственной в отклике, проблемы упорядочения не возникает. Поле замены пусто, поэтому используется шаблон, возвращенный в поле regexp. Применим выражение regexp ко всему значению URN для проверки наличия соответствия. Последовательность выражения для замены \2 возвращает подстроку example.com. Поскольку поле флагов пусто, поиск не является завершающим и наш следующий запрос к DNS возвратит большее число записей NAPTR, где новое доменное имя example.com.

Отметим, что правило не выделяет полное доменное имя из CID, предполагая вместо этого, что CID происходит от хоста и выделяется домен для этого хоста. Когда все хосты (такие, как bar) могут иметь свои записи NAPTR, поддержка таких записей для всех машин сайта может стать чересчур обременительной. Шаблоны здесь не подойдут, поскольку они возвращают результат только в тех случаях, когда в системе отсутствует точное соответствие для имен.

Запись, возвращенная для запроса example.com может иметь вид:

example.com.

;; order pref flags service regexp replacement

IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.n

IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.

IN NAPTR 100 50 "s" "http+N2IH-N2C+N2R...... www.example.com.

Продолжая этот пример, отметим, что значения полей Order и Preference равны для всех записей, поэтому клиент может выбрать любую запись. Приложение определяет, что флаг 'a' указывает на завершение поиска и выводом перезаписи будет доменное имя, для которого следует запросить запись типа A. Когда клиент сделает это, он узнает хост, его IP-адрес, протокол и доступные для этого протокола службы. Этой информации клиенту достаточно для контакта с сервером и передачи тому запроса о URN.

¹²Uniform Resource Name Resolver Discovery Service - служба обнаружения преобразователей однотипных имен ресурсов.

rfc.com.ru 4 rfc.com.ru

Перевод RFC 3403

Повторно используем регулярное выражения, содержащее \2, для выделения доменного имени из CID и \. для соответствия символу '.', разделяющему компоненты доменного имени. Поскольку \ является escape-символом, включение самого этого символа должно использовать предшествующий ему дополнительный символ \ (escape). Для случая приведенной выше записис cid.urn.arpa регулярное выражение в master-файле должно иметь вид "!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". Когда клиент получит реальную запись, та будет преобразована к виду "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i".

6.2 Пример E164

Рабочая группа ENUM подготовила спецификацию сервиса, который позволяет отображать телефонные номера на URI [18]. Строка AUS для Приложения ENUM представляет собой телефонный номер E.164 с удаленными символами “-”. Первое общеизвестное правило обеспечивает удаление из телефонного номера ненужные символы¹³ и полученное в результате значение используется как первый Ключ. Например, телефонный номер 770-555-1212¹⁴ в формате E.164 будет иметь вид +1-770-555-1212. Полученный в результате преобразования первый Ключ будет иметь значение 17705551212.

В настоящее время ENUM является единственным приложением, использующим эту Базу данных. Спецификация приложения задает для преобразования первого Ключа в формат, корректный для Базы данных вставку точек между цифрами и добавления строки “e164.arpa.” в конце. Для упомянутого выше телефонного номера преобразованный ключ будет иметь значение “2.1.2.1.5.5.5.0.7.7.1.e164.arpa.”. Это доменное имя используется для нахождения Правил перезаписи, как записей NAPTR.

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

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .

Оба приложения ENUM [18] и URI Resolution [4] используют флаг 'u'. Это флаг говорит, что Правило является завершающим и результатом служит значение URI, которое содержит информацию, требуемую для обращения в телефонную компанию. ENUM также использует такой формат для своих параметров сервиса (Service Parameters). Это показывает, что для доступа к телефонному сервису поддерживается протокол Session Initiation Protocol или SMTP (электронная почта).

7. Совет администраторам DNS

Остерегайтесь регулярных выражений. Они не только достаточно сложны сами по себе, но ещ и взаимодействуют с DNS, как было отмечено выше. Любые символы обратной дробной черты (\) в регулярном выражении должны указываться дважды, чтобы в отклике на запрос появился одиночный символ \. Более того, использование двойных символов \ возможно не было протестировано со всеми реализациями серверов DNS.

Чтобы не возникало ненужных проблем с файлами зон, администраторам рекомендуется использовать при написании правил перезаписи свойство регулярных выражений 'default delimiter'¹⁵. По спецификации DDDS регулярные выражения начинаются с символа, который будет использоваться в качестве ограничителя. Следовательно, если первым символом регулярного выражения является восклицательный знак (например), регулярное выражение можно создать с использованием меньшего числа символов \.

8. Примечания

Клиент должен обрабатывать множество записей NAPTR, упорядоченных по значению поля Order, и недопустимо просто использовать первую запись, которая обеспечивает известную комбинацию Service Parameter.

Если множество записей RR имеют одинаковое значение поля Order и все прочие критерии дают одинаковый результат, клиенту следует использовать значение поля Preference для выбора следующей рассматриваемой записи NAPTR. Однако, поскольку во многих случаях существуют предпочтительные протоколы или службы, клиент может использовать для сортировки записей иные критерии.

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

9. Согласование с IANA

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

10. Вопросы безопасности

Записи NAPTR, подобно всем прочим записям DNS, могут подписываться и проверяться в соответствии с процедурами DNSSEC.

Эта База данных делает идентификаторы из других пространств имен объектами тех же атак, которым подвержены обычные доменные имена. Поскольку этот вопрос не был разрешен ранее, он может рассматриваться (или не рассматриваться) как проблемы.

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

Литература

[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401¹⁶, October 2002.

[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402¹⁶, October 2002.

[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403¹⁶, October 2002.

¹³Все символы, за исключением цифр. Прим. перев.

¹⁴Номер телефона в США. Прим. перев.

¹⁵Используемый по умолчанию ограничитель.

¹⁶Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 5 rfc.com.ru

Перевод RFC 3403

[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404¹⁶, October 2002.

[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405¹⁶, October 2002.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119¹⁶, March 1997.

[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234¹⁶, November 1997.

[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.

[12] IEEE, "IEEE Standard for Information Technology – Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.

[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[14] Moats, R., "URN Syntax", RFC 2141, May 1997.

[15] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.

[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.

[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.с

[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

Адрес автора

Michael Mealling

VeriSign

21345 Ridgetop Circle

Sterling, VA 20166

EMail: michael@neonym.net

URI: http://www.verisignlabs.com

Полное заявление авторский прав

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

Перевод на русский язык Николай Малых

BiLiM Systems nmalykh@bilim.com

rfc.com.ru


На главную




Network Working Group Request for Comments: 3403 Obsoletes: 2915, 2168 Category: Standards Track	M. Mealling VeriSign October 2002

Система DDDS. Часть 3 – База данных DNS Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database Статус документа Этот документ содержит спецификацию стандартного протокола, предложенного сообществу Internet, и служит приглашением к дискуссии в целях развития. Текущее состояние стандартизации и статус описанного здесь протокола можно узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений. Авторские права Copyright (C) The Internet Society (2002). All Rights Reserved. Тезисы Этот документ описывает Базу данных DDDS¹, использующую систему DNS² в качестве распределенной базы Правил. Ключами являются доменные имена и Правила представляются с использованием записей NAPTR RR³. Поскольку этот документ отменяет действие RFC 2915, он является официальной спецификацией для записей NAPTR в DNS. Документ также является частью серии, полностью указанной в документе "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

Оглавление

1. Введение ................................................................................................................................................................................ ...... .................... 1 2. Терминология ............................................................................................................................................................................... ...... ........... 2 3. Спецификация Базы данных DDDS ........................................................................................................................................................ ..2... 4. Формат NAPTR RR ........................................................................................................................................................ ..... ........................... 3 4.1 Формат пакета ................................................................................................................................................................................... ....3... 4.2 Обработка дополнительной информации ..................................................................................................................... .................... 4 4.2.1 Обработка раздела Additional серверами DNS ...................................................................................................... ...... ............. 4 4.2.2 Обработка раздела Additional Information преобразователями и приложениями ........................................... ................... 4 4.3 Формат Master-файла ..................................................................................................................................................................... ....4... 5. Спецификация Приложения ................................................................................................................................................................. ...... 4. 6. Примеры .......................................................................................................................................................................................... ............. 4 6.1 Пример URN ........................................................................................................................................................................................ 4... 6.2 Пример E164 ........................................................................................................................................................................................ 5... 7. Совет администраторам DNS ........................................................................................................................................................ .... .......... 5 8. Примечания .................................................................................................................................................................................................. 5... 9. Согласование с IANA ........................................................................................................................................................ ....... ...................... 5 10. Вопросы безопасности ................................................................................................................................................. .............................. 5 Литература ..................................................................................................................................................................................................... ..5... Адрес автора ........................................................................................................................................................................................... ......... 6 Полное заявление авторский прав ................................................................................................................................................. ................ 6 *1. Введение* Система DDDS обеспечивает возможность организации связей между строками данных для поддержки систем передачи полномочий (делегирования0 с динамической конфигурацией. Работа DDDS основана на отображении некой уникальной строки на данные, хранящиеся в Базе данных DDDS путем итеративного применения правил преобразования строк до выполнения условий завершения. Этот документ описывает способ, при котором используется система DNS в качестве хранилища Правил, обеспечивающих функционирование Приложения DDDS. Документ не задает какого-либо конкретного приложения или сценария использования. Вся серия документов описана в "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. Важно подчеркнуть, что понимание любого документа этой серии невозможно без прочтения других документов.

¹Dynamic Delegation Discovery System – динамическая система детектирования передачи полномочий. ²Domain Name System – система доменных имен ³Naming Authority Pointer Resource Record – запись для указателя на уполномоченный сервер именования. rfc.com.ru		rfc.com.ru



	Перевод RFC 3403 Описанная здесь запись DNS NAPTR была изначально предложена рабочей группой URN в качестве способа представления наборов правил в DNS, позволяющих разобрать делегированную часть URI⁴ таким образом, чтобы она могла быть изменена и ределегирована с течением времени. В результате получились записи RR⁵, включающие регулярные выражения, которые используются клиентскими программами для преобразования строк в доменные имена. Регулярные выражения были выбраны за их возможность компактно выражать большие объемы информации для передачи в обычно небольших пакетах DNS. Со временем процесс был обобщен для других Приложений и Баз данных о Правилах. В этом документе определена База данных о Правилах без задания какого-либо Приложения, поскольку может существовать множество Приложений, способных использовать эту Базу данных о Правилах. 2. *Терминология* Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [6]. Все прочие термины, особенно выделенные шрифтом, заимствованы из [3]. 3. *Спецификация Базы данных DDDS* General Description - общее описание Эта база данных использует систему DNS, описанную в [8] и [7]. Набором символов, используемых для задания различных значений записей NAPTR является UTF-8 [17]. Следует соблюдать осторожность в тех случаях, когда ввод или вывод выражений для замены содержит коды, выходящие за пределы эквивалентности ASCII/Unicode в UTF-8 - любые символы UTF-8 интерпретируются как последовательности кодовых точек (code-point), а не байтов. Это сделано для поддержки других языков в расширенных регулярных выражениях POSIX⁶, чтобы обеспечить возможность соответствия предназначенным кодовым точкам. Недопустимо писать выражения для замены так, чтобы они зависели от локальных установок POSIX⁷, поскольку это приведет к потере выражениями для замены их универсальности в применении. Все записи о ресурсах DNS имеют связанное с ними значение времени жизни TTL⁸. По истечении с момента отыскания записи соответствующего числа секунд корректность записи теряется м нужно сделать новый запрос для получения новых записей. Таким образом, как указано в Алгоритме DDDS, могут возникать ситуации, когда срок действия данного Правила истекает. В тех случаях, когда приложение пытается вернуться к ранее найденным наборам Правил (в случае неподходящего пути передачи полномочий или при отказе сервера) приложение должно обеспечить гарантию того, что ни одна из записей, к которым происходит возврат, не перестала быть корректной по времени жизни. Если истек срок действия хотя бы одной записи приложение должно вернуть процесс на первый шаг алгоритма. Key Format - формат ключей Ключ представляет собой корректно сформированное доменное имя DNS. Lookup Request - поисковый запрос Чтобы запросить набор правил для данного Ключа, клиент вводит запрос, соответствующий стандартным правилам DNS, для записис NAPTR RR, соответствующей данному доменному имени. Lookup Response - отклик при поиске Отклик на запрос для данного Ключа (доменное имя) будет серией записей NAPTR. Формат записи NAPTR описан в главе 4. Rule Insertion Procedure процедура вставки правил Правила вставляются путем добавления новых записей в соответствующую зону DNS. Если Правило производит Ключ, который существует в конкретной зоне, тогда только объект, имеющий административный контроль над этой зоной, может задавать Правило, связанное с таким Ключом. Collision Avoidance - предотвращение конфликтов В том случае, когда два Приложения могут использовать эту Базу данных (на практике это случай использования базы приложениями ENUM и URI Resolution, описанный в параграфе 6.2), возможно возникновение конфликта между правилами, когда в домене появляются две записи NAPTR, применимые более, чем к одному Приложению. Существуют три способа предотвращения конфликтов. ♦ Создание в домене новой зоны, которая содержит только записи NAPTR, которые подходят для Приложения. Например, все записи URI Resolution могут размещаться в зоне urires.example.com, а все записи ENUM - в зоне enum.example.com. В том случае, когда такое решение невозможно по причине отсутствия контроля над восходящим делегированием⁹, следует использовать второй метод. ♦ Создание регулярного выражения, содержащего часть строки AUS¹⁰, достаточную для однозначной идентификации приложения. Например, URI Resolution может использовать имя схемы слева для привязки регулярного выражения к соответствию этой схеме. Связанные с ENUM записи в той же зоне могут привязываться слева к соответствию символу "+", который определен в ENUM как начало каждой строки AUS. В результате данной строке AUS может соответствовать лишь одна из записей, а не две.

	⁴Uniform Resource Identifiers – однотипные идентификаторы ресурсов. ⁵Resource Record – запись о ресурсах. ⁶POSIX Extended Regular Expression ⁷POSIX locale ⁸Time To Live ⁹В оригинале “upstream delegation” - передача полномочий вверх по иерархии. Прим. перев. ¹⁰Application Unique String – уникальная строка приложения rfc.com.ru 2 rfc.com.ru



	Перевод RFC 3403 Повторно используем регулярное выражения, содержащее \2, для выделения доменного имени из CID и \. для соответствия символу '.', разделяющему компоненты доменного имени. Поскольку \ является escape-символом, включение самого этого символа должно использовать предшествующий ему дополнительный символ \ (escape). Для случая приведенной выше записис cid.urn.arpa регулярное выражение в master-файле должно иметь вид "!^urn:cid:.+@([^\\.]+\\.)(.)$!\\2!i". Когда клиент получит реальную запись, та будет преобразована к виду "!^urn:cid:.+@([^\.]+\.)(.)$!\2!i". 6.2 Пример E164 Рабочая группа ENUM подготовила спецификацию сервиса, который позволяет отображать телефонные номера на URI [18]. Строка AUS для Приложения ENUM представляет собой телефонный номер E.164 с удаленными символами “-”. Первое общеизвестное правило обеспечивает удаление из телефонного номера ненужные символы¹³ и полученное в результате значение используется как первый Ключ. Например, телефонный номер 770-555-1212¹⁴ в формате E.164 будет иметь вид +1-770-555-1212. Полученный в результате преобразования первый Ключ будет иметь значение 17705551212. В настоящее время ENUM является единственным приложением, использующим эту Базу данных. Спецификация приложения задает для преобразования первого Ключа в формат, корректный для Базы данных вставку точек между цифрами и добавления строки “e164.arpa.” в конце. Для упомянутого выше телефонного номера преобразованный ключ будет иметь значение “2.1.2.1.5.5.5.0.7.7.1.e164.arpa.”. Это доменное имя используется для нахождения Правил перезаписи, как записей NAPTR. Для нашего примера мы можем получить в результате следующие записи NAPTR: *$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.$!sip:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.$!mailto:information@foo.se!i" .* Оба приложения ENUM [18] и URI Resolution [4] используют флаг 'u'. Это флаг говорит, что Правило является завершающим и результатом служит значение URI, которое содержит информацию, требуемую для обращения в телефонную компанию. ENUM также использует такой формат для своих параметров сервиса (Service Parameters). Это показывает, что для доступа к телефонному сервису поддерживается протокол Session Initiation Protocol или SMTP (электронная почта). *7. Совет администраторам DNS* Остерегайтесь регулярных выражений. Они не только достаточно сложны сами по себе, но ещ и взаимодействуют с DNS, как было отмечено выше. Любые символы обратной дробной черты (\) в регулярном выражении должны указываться дважды, чтобы в отклике на запрос появился одиночный символ \. Более того, использование двойных символов \ возможно не было протестировано со всеми реализациями серверов DNS. Чтобы не возникало ненужных проблем с файлами зон, администраторам рекомендуется использовать при написании правил перезаписи свойство регулярных выражений 'default delimiter'¹⁵. По спецификации DDDS регулярные выражения начинаются с символа, который будет использоваться в качестве ограничителя. Следовательно, если первым символом регулярного выражения является восклицательный знак (например), регулярное выражение можно создать с использованием меньшего числа символов \. *8. Примечания* Клиент должен обрабатывать множество записей NAPTR, упорядоченных по значению поля Order, и недопустимо просто использовать первую запись, которая обеспечивает известную комбинацию Service Parameter. Если множество записей RR имеют одинаковое значение поля Order и все прочие критерии дают одинаковый результат, клиенту следует использовать значение поля Preference для выбора следующей рассматриваемой записи NAPTR. Однако, поскольку во многих случаях существуют предпочтительные протоколы или службы, клиент может использовать для сортировки записей иные критерии. При отказе после перезаписи клиенту настоятельно рекомендуется сообщить об отказе, а не просто переходить к использованию других путей перезаписи. *9. Согласование с IANA* Значения полей Services и Flags будут определяться Приложением, использующим эту Базу данных DDDS. Это может потребовать механизма регистрации и связанных с такой регистрацией ресурсов IANA. Данная спецификация таких требований не включает. *10. Вопросы безопасности* Записи NAPTR, подобно всем прочим записям DNS, могут подписываться и проверяться в соответствии с процедурами DNSSEC. Эта База данных делает идентификаторы из других пространств имен объектами тех же атак, которым подвержены обычные доменные имена. Поскольку этот вопрос не был разрешен ранее, он может рассматриваться (или не рассматриваться) как проблемы. Следует проверять корректность регулярных выражений, не просто передавая из чему-либо типа PERL, поскольку в такие выражения может быть включен произвольный код, который будет выполнен в системе. *Литература* [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401¹⁶, October 2002. [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402¹⁶, October 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403¹⁶, October 2002.

	¹³Все символы, за исключением цифр. Прим. перев. ¹⁴Номер телефона в США. Прим. перев. ¹⁵Используемый по умолчанию ограничитель. ¹⁶Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 5 rfc.com.ru