RFC: 3404
Оригинал: Dynamic Delegation Discovery System - Part Four: The Uniform Resource Identifiers (URI) Resolution Application
Предыдущие версии: RFC 2168, RFC 2915
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3404, Страница 7 из 12

5. Примеры

5.1. Пример использования URN

Рассмотрим URN из гипотетического пространства имен FOO. Номера FOO служат идентификаторами приблизительно для 30 миллионов зарегистрированных компаний по всему миру; идентификаторы распределяет и поддерживает компания Fred, Otto and Orvil, Inc. URN могут иметь вид:

urn:foo:002372413:annual-report-1997

Первым шагом процесса преобразования будет поиск информации о пространстве имен FOO. Идентификатор пространства имен [8] "foo" создается из URN путем добавления к '.urn.arpa.' префикса 'foo', что дает в результате 'foo.urn.arpa.'. Далее делается запрос к DNS для получения записей NAPTR для этого домена. Результат запроса имеет вид:

foo.urn.arpa.
;;      order pref flags service          regexp        replacement
IN NAPTR 100  10  "s" "foolink+I2L+I2C"  ""   foolink.udp.example.com.
IN NAPTR 100  20  "s" "rcds+I2C"          ""  rcds.udp.example.com.
IN NAPTR 100  30  "s" "thttp+I2L+I2C+I2R" ""  thttp.tcp.example.com.

Поле order содержит одинаковые значения, показывающие отсутствие упорядочения. Поле preference показывает, что провайдер предпочитает, чтобы клиенты использовали специальный протокол foolink, после этого RCDS и в последнюю очередь THTTP. Все записи содержат флаг s, показывающий, что запись является завершающей и следующим шагом является получение от DNS записи SRV для данного доменного имени.

Поле service говорит, что при использовании протокола foolink можно вводить запросы I2L, I2C или I2R для получения URI или задавать некоторые более сложные вопросы о ресурсе. Можно использовать сервис RCDS [12] для получения некоторых метаданных, тогда как THTTP можно использовать для получения URI, соответствующего текущему местоположению ресурса.

Предположим, что клиент не знает протокола foolink, но знает RCDS. Следующим шагом будет поиск записей SRV RR для имени rcds.udp.example.com, котрый даст нам список хостов, способных предоставить требуемые услуги преобразования. Этот список может иметь вид:

;;                          Pref Weight Port Target
rcds.udp.example.com  IN SRV 0    0    1000 deffoo.example.com.
                      IN SRV 0    0    1000 dbexample.com.au.
                      IN SRV 0    0    1000 ukexample.com.uk.

Список содержит три хоста, способных выполнить преобразование и указывает номер порта, который следует использовать для связи с сервером RCDS (получить сведения об интерпретации приведенных выше полей можно из спецификации SRV [9]). Здесь существует возможность оптимизации. RFC 3403 определяет возможность использования раздела Additional Information. В этом случае записи SRV могут возвращаться в качестве дополнительной информации при завершающем поиске NAPTR (вместе с записями A для этих SRV). Эти записи обеспечивают возможность существенной оптимизации. При использовании этого в комбинации со большими значениями TTL для записей *.urn.arpa. среднее число обращений к DNS для преобразования большинства URI будет приближаться к 1.

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

Отметим также, что может использоваться дополнительный первый шаг, на котором URN преобразуется как базовый вариант URI путем просмотра urn.uri.arpa. Результирующее правило будет задавать, что NID выделяется и URN и суффикс '.urn.arpa.' добавляется для получения первого ключа 'foo.urn.arpa.'.

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