AAA

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

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

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

Тезисы

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

Оглавление

1. Введение

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

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

Описанная здесь запись 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

4. Формат NAPTR RR

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

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

                                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                  /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

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

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, приложения, желающие использовать эту базу данных, должны определить перечисленные ниже значения.

6. Примеры

6.1 Пример URN

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

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

urn:cid:199606121851.1@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   ""    ""  "!^urn: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.
IN NAPTR 100  50  "a"    "rcds+N2C"          ""   cidserver.example.com.
IN NAPTR 100  50  "s"    "http+N2L+N2C+N2R"  ""   www.example.com.

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

Повторно используем регулярное выражения, содержащее \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 Doman Name System (DNS) Database", RFC 3403, October 2002.
  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 US
URI: http://www.verisignlabs.com
EMail: ten.mynoen@leahcim

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

Николай Малых, moc.milib@hkylamn