RFC: 3405
Оригинал: Dynamic Delegation Discovery System - Part Five: URI.ARPA Assignment Procedures
Категория: Лучший современный опыт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3405, Страница 5 из 9

4. Требования к указаниям

Делегирование пространства имен может происходить двумя путями. Для большинства URI делегируемый ключ будет жестко определяться самим идентификатором (например, имя хоста для HTTP URI). Синтаксис местоположения ключа в этом случае предопределен синтаксисом схемы. В других случаях новый ключ может быть частью самого указания. Функциональный эквивалент этого можно выразить словами "если данное правило выполняется, оно всегда является ключом".

Для минимизации нагрузки по запросам в зоны URI.ARPA и URN.ARPA предлагается устанавливать для этих зон экстремально большое время жизни TTL (возможно, измеряемое годами).

Таким образом, для любого префикса URI или пространства имен URN, в которых указания по преобразованию будут склонны к изменению, актуальные правила следует хранить в какой-либо другой (менее статичной) зоне DNS, а в зоне URI.ARPA или URN.ARPA следует использовать стабильную запись NAPTR, которая будет служить для передачи полномочий в менее статичную зону.

Например пространство имен URN 'foo' имеет гибкие правила передачи полномочий. Вместо включения этих правил в зону URN.ARPA туде помещается запись, передающая полномочия хранения этих правил серверу имен с меньшим временем жизни записей. Такая запись в зоне URN.ARPA будет иметь вид:

foo     IN NAPTR 100 10  ""  "" "" urn-resolver.foo.com.

Когда клиент начинает процесс преобразования. Он сначала будет запрашивать foo.URN.ARPA для получения показанной выше записи, а на втором этапе будет запрашивать 'urn-resolver.foo.com' для получения записей NAPTR, содержащих правила преобразования. TTL на корневом уровне имеет очень большое значение. Значение TTL в 'urn-resolver.foo.com' значительно меньше.

Схема URI 'http', напротив, жестко придерживается определенного синтаксиса, который указывает, что искомый хост задан в самом значении URI. Поскольку этот синтаксис не меняется, правило можно включать в зоеу URI.ARPA. Запись будет иметь вид:

http    IN NAPTR 100 100 "" ""  "/http:\\/\\/([^\\/:]+)/\\2/i" .

Таким образом, второй шаг преобразования будет заключаться в использовании доменного имени из URI в качестве следующего ключа в цикле. Если, например, данная запись NAPTR является завершающей и содержит некое имя хоста в поле replacement, клиент может обращаться к этому хосту с запросом о данном URI.

Страница 5 из 9

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