RFC: 3403
Оригинал: Dynamic Delegation Discovery System - Part Three: The Domain Name System (DNS) Database
Предыдущие версии: RFC 2168, RFC 2915
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3403, Страница 6 из 10

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".

2007 - 2017 © Русские переводы RFC, IETF, ISOC.