RFC-2915. Записи DNS типа NAPTR. Перевод
Request for Comments: 2915
Updates: 2168
Category: Standards Track
M. Mealling Network Solutions, Inc.
R. Daniel DATAFUSION, Inc.
Сентябрь 2000
Записи Ресурсов Указателей Авторитетных Имен (NAPTR) DNS
Перевод RFC-2915. Записи DNS типа NAPTR
Статус этого документа
Этот документ определяет стандарты путей Интернет-протоколов для сообщества Интернета, и просит их обсудить и дать предложения для его усовершенствования. Пожалуйста обратитесь к текущему изданию "Официальных стандартных протоколов Интернета" (STD 1) для уточнения состояния стандартизации и статуса этого протокола. Распространение этой записки неограничено.
Объявление об авторском праве
Copyright © The Internet Society (2000). All Rights Reserved.
Copyright © Перервод на русский язык. Voipx Inc. 2007
Резюме
Этот документ описывает запись способа системы доменых имен (DNS), которая определяет правило подстановки основанное на регулярном выражении, применямое для существующей строки, которое произведет новое обозначение домена или единообразный идентификатор ресурса (URI). В зависимости от значения флагов области ресурсной записи, результирующее обозначение домена или URI может использоваться в последовательных запросах для авторитетных имен зон (NAPTR) записи ресурсов (чтобы делегировать искомое имя) или как вывод целого процесса, для которого эта система используется (сервер решения для разрешения URI, обслуживание URI для ENUM стиля номеров E.164 к отбору URI отбору и т.д).
Это позволяет использовать DNS для услуг поиска для большого спектра многообразных имен ресурсов (включая URI), которые не соответствуют синтаксису имен доменов. Причина действий этой сферы от URN систем иследований ресурсов до перехода устаревших сервисов к новым доменам
1. Введение
Этот RR был первоначально создан рабочей группой URN [3] как способ кодировать правил-наборjd в DNS так, чтобы делегированные разделы URI могли бы быть расчленены таким способом, что бы они могли бы быть изменены и повторно делегированы через какое-то время. Результатом была Запись Ресурсов (RR) , которая включала регулярные выражение, которое должно использоваться в соответствии с клиентской программой, чтобы перезаписать строку названия домена. Регулярные выражения были выбраны за их компактность благодаря многозначным соотношений позволяет раскодировать много информации при довольно малых пакетах DNS.
Функция перезаписи строки в соответствии с правилам записи имеет ценность в различных отдельных приложениях. Этот документ определяет базисные допущения, которым должны твердо придержаться все эти приложения. Это определяет не причины использования перезаписи, а чем являются ожидаемые результаты, или для чего они используются. Этим специфицируются приложения, для которых утсанавливается, что они используют запись NAPTR и алгоритмы, находящиеся внутри их контекста.
Флажки и остальные поля также специфицированы в RR для различных способов контроля процедуры перезаписи или предоставления информацию о способе связи хоста с именем домена, что является результатом перезаписи.
Итоговый результат - у RR имеются отдельные поля взаимодействующие нетривиальным, но осуществимым способом. Этот документ определяет такие поля и значения в них.
Этот документ не определяет приложения, который использует эти функциональные возможности перезаписи. Взамен это определяет только механизм, как это сделать. Как это выполнить, какие правила относительно входов, и резервирование типов правил, используемых в других документах, являющихся полными спецификациями частных приложений. Это разделение обусловлено рядом различий в приложениях, которые хотят предполагают использование правил перезаписи в процессе поиска. Каждое из них имеет весьма разные причин, как и почему оно использует службу, требуя, что определение услуг было общим.
Ключевые слова "ДОЛЖЕН", "НЕ ДОЛЖЕН", "ТРЕБУЕТ", "ДОЛЖНО", "БУДЕТ", "НЕ БУДЕТ", "БЫЛ БЫ", "НЕ БЫЛ БЫ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ОПЦИОНАЛЬНО" в этом документе следует интерпретировать, как описано в RFC 2119.
Все сноски к единообразному идентификатору ресурса (URI) в этом документе твердо соответствуют 'absoluteURI' приведенном в "Колекции ABNF" находящемся в RFC 2396 [9]. Специально - семантика ссылок URI не применяется, так как базовая концепция здесь не имеет значение.
2. Формат NAPTR RR
Формат NAPTR RR дан ниже. Типовой код DNS [1] для NAPTR равна 35.
Время жизни (TTL) класса типа порядка ссылок флагов службы регулярных выражений замены
Домен
Название домена, на который ссылается эта запись ресурса. Это 'ключ' для этой записи в базе данных. Это значение может являться первым известным ключем (например .uri.arpa) или новым ключем, который является результатым замены или перезаписи по регулярному выражению.
Помимо этого, имеются требования стандарта DNS [1].
Время жизни (TTL)
Значения из стандарта DNS [1].
Класс
Значения из стандарта DNS [1].
Тип
Код типа [1] для NAPTR - 35.
Порядок (Order)
16-разрядное целое число без знака, точно определяющее порядок, в котором ДОЛЖНЫ быть ОБРАБОТАНЫ записи NAPTR, чтобы гарантировать правильное упорядочение результата. Низкие значения обработываются раньше высоких значений, и когда найден NAPTR "соответствующий" целевому, клиент НЕ ДОЛЖЕН рассматривать другой NAPTR с более высоким значением порядка (за исключением описаных ниже полей Флажков).
Предпочтение (Preference)
16-разрядное целое число без знака, которое определяет очередность, в, который NAPTR помещает записи с равными значениями "порядка", меньшие значения ДОЛЖНО быть ОБРАБОТАНЫ раньше больших значений. Это подобно полям предпочтения записей MX, и это используется администраторами домена, которые могут направлять клиентов к хостам с большим или меньшим весом протокола. Клиент МОЖЕТ увидеть записи с более высокими значениями предпочтения, если это имеет вескую причину делать так, не учитывая предпочтения протокола или сервиса.
Основная разница между Порядком и Предпочтением - то, что, как только соответствие найдено, то клиент НЕ ДОЛЖЕН рассмотривать записи с другим Порядком, но они МОГУТ обрабатывать записи с тем же самым Порядком, но различными Предпочтением. То есть, предпочтение используется, чтобы дать возможность рассмотреть важность правил с точки зрения зоны компетенции, но не с точки зрения обычной загрузки.
Флажки
, содержащая флажки, чтобы управлять аспектами перезаписи и интерпретации полей в записи. Флажки - одиночные символы из множества [A-Z 0-9]. Случаи алфавитных символов не значительны.
В настоящее время определены только четыре флажка: "S", "A", "U" и "P". Флажки "S", "A" и "U" обозначают окончание поиска.
Это означает что, эта запись NAPTR является последняя и что флажок определяет, какая должна быть следующая стадия. Флажк "S" помечают, что следующий поиск должен быть для записей типа SRV [4]. Для дополнительной информации относительно того, как NAPTR использует тип записи SRV см. раздел 5. Флафок "A" обозначает, что следующий способ поиска должен быть по записям A, AAAA или A6. Флажок "U" помечает, что следующий шаг - не DNS поиск, а результатом поля Regexp является URI, который поддеривается продуктом "absoluteURI", найденной по ABNF RFC 2396 [9]. Поскольку могут иметься приложения, использующие NAPTR в аспекте поиска URI с инкременцией, необходимо знать, что это может вызывать зацикливание и необходимо приедпринимать соответствующие действия.
Флажок "P" говорит, что для оставшейся части со стороны приложения должен выполняться прикладной алгоритм в режиме специфического протокола.
Новое множество правил идентифицируется в соответствии с Протоколом, специфицированым в поле Сервис. Запись, которая содержит флажок 'P' - последняя запись, которая интерпретируется правилами, точно установленными в предыдущем документе. Новые правила зависят от приложения, для которого они используются и специфицированного протокола. Например, если приложение - URI RDS, и протокол - WIRE, то новое множество правил регулируется алгоритмами, относящимися к спецификации WIRE HTTP и не предудыщего документа.
Остающиеся алфавитные флажки зарезервированы для будущих версий NAPTR спецификации. Числовые флажки могут использоваться для локального экспериментирования. Флажки S, A, U и P взаимно исключающие и библиотеки решений МОГУТ сообщить об ошибке, если дан больше чем один. (Экспериментальный код и код поддержки обеспечения NAPTRS более вероятно сообщит об ошибке, чем клиент типа браузера). Ожидается, что кратные флажки будут использоваться в будущем, так что разработчики НЕ ДОЛЖНЫ принимать, что в поле флажков может быть только 0 или 1 символ). Наконец, если клиент обнаруживает запись с неизвестным флагом, он ДОЛЖЕН игнорировать ее и переходите к следующей записи. Этот критерий имеет приоритет даже над полем "Order". Так как флажки могут управлять интерпретацией того, что помещенно поле, новый флажок мог бы изменять интерпретацию регулярного выражения и/или заменять поле так, что невозможно определить, согласовала ли запись данному адресату.
"S", "A", и флажки "U" называются флажками 'терминала', так как они останавливают выполнение цикла алгоритма перезаписи. Если эте флажки не ставить, клиент может предположить, что в названии домена существует другой NAPTR RR, произведенный в соответствии с текущим правилом подстановки. Так как флажок "P" указывает на новый алгоритм, он может или не может быть 'терминалом'.
Таким образом, клиент не может принимать, что другой NAPTR существует, так как этот случай определен в другом месте.
DNS серверы МОЖЕТ интерпретировать эти флажки и значения и использованать информацию, чтобы включить соответствующие SRV и A, AAAA или A6 записи в дополнительной информационной части DNS пакета. Клиенту рекомендуется проверить дополнительную информацию, но он не обязан делать это.
Сервисы
Определяет сервисы, доступное при перезаписи пути. Может также определяться конкретный частный протокол, который используется, чтобы обмениваться сообщениями с сервисом. Протокол ДОЛЖЕН быть ОПРЕДЕЛЕН, если поле флажков показывает, что NAPTR является терминальным. Если протокол определен, но поле флажков не показывает, что NAPTR - терминал, следующий поиск ДОЛЖЕН БЫТЬ для NAPTR. Если протокол неизвестен, клиент МОЖЕТ сам определить выполнить или нет следующий поиск, но на такое поведение НЕЛЬЗЯ операться.
Поле сервис область может принимать любое из значений указанных ниже (используется расширение НОРМАЛЬНОЙ ФОРМЫ БЕКУСА-НАУРА RFC 2234 [5)]:
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; Протокол и поле rs ограничены 32
; символами и должны начинаться
; с буквы
Например, опциональный протокола дополняется нулем или большей цифрой номера версии сервиса. Каждая версия сервиса обозначается предыдущим номером '+' какая-то цифра.
Обращаем внимание, что пустая строка - также допустимое поле сервиса. Это обычно можно видеть в начале ряда правил, когда невозможно узнать, какой сревисы и протоколы будут предлагаться под конкретные сервисы.
Фактический формат запроса сервиса и реакции на запрос будет определен в соответствии с версией протокол, и является темой других документов. Потребности Протоколов не предлагает все сервисы. Обозначения для запросов на обслуживание должны быть сформированы из множества набора символов [A-Z 0-9]. Случай буквеных символов не является существенным.
Список "допустимых" протоколов для любой NAPTR записи это любой протокол, который осуществляет отдельные или все сервисы, определенные для NAPTR приложения. В настоящее время(постоянно), THTTP [6] - единственый протокол, который, как известно, выполняет это требование на время публикации. Любой другой протокол, который должен использоваться, должен иметь документацию с указанием:
Список допустимых Решения Сервисов определен в соответствии с документами, которые точно определяют индивидуальный NAPTR основанных приложений.
Следует отметить, что интерпритации этого поля подчинена изменениям новых флажков, и что текущая спецификация ориентирована на сообщения клиентов, на обмене с URN-резольвером
Регулярные выражения (Regexp)
Строка, содержащее выражение подстановки, которое применяется к оригинальной строке, переданой клиентом, чтобы создать следующее имя домена для поиска. Грамматика выражения подстановки дана в следующем разделе.
Регулярные выражения НЕ ДОЛЖНЫ, использоваться в кумулятивном режиме, то есть они должны примениться только к первоначальной строке, заданой клиентом, никогда к названию домены, полученому предыдущим NAPTR запросом. Это искушает для некоторых приложений, но опыт показал что такое использование, будет крайне подвержено ошибкам, склонна к погрешностям и чрезвычайно трудна для отладки.
Замена (Replacement)
Следующее НАЗВАНИЕ запроса для NAPTR, SRV или адреса записи делается в зависимости от значения поля флажков. Это ДОЛЖНО БЫТЬ полностью квалифицированное название домена. Если и пока это не будет разрешено будущими стандартами, для этого поля не должно использоваться сжатое названия.
3. Грамматика Выражений Подстановок
Содержание поля регулярного вырожения (regexp) - выражение подстановки. Регулярные выражения в стиле True sed (1) и Perl не подходят для использования в этом приложении по ряду причин, вытекающих из требований интернационализации и ограничений на обратный возврат, следовательно содержание поля регулярного выражения ДОЛЖНО следовать грамматике, указаной ниже:
subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ...ere = POSIX Extended Regular Expression POSIX расширеное регулярное выражение repl = 1 * ( OCTET / backref ) backref = "\" 1POS_DIGIT flags = "i" POS_DIGIT = %x31-39 ; 0 is not an allowed backref ; не допустим в backref
Определение раширеного регулярного выражения POSIX может быть найдено в [8], раздел 2.8.4.
Результат применения выражения замены к оригинальным URI ДОЛЖЕН привести или к строке, которая повинуется синтаксису для имен домена DNS [1] или к URI [9], если поле Flags содержит 'u'.
Так как для поля regexp могут быть неправильно определенны, так что может быть построено некорректное название домена, программное обеспечение клиента перед созданием запроса ДОЛЖНО проверить, что результат - допустимое имя домена DNS.
Возвращаемое выражения в изменяемое части выражения замены заменены строкой символов (возможно пустой), ограниченой '(' и ')' в ERE части выражения замены. N - единственная цифра от 1 до 9, включительно. Это определяет N-е возвращаемое выражение, тот, которое начинается с N'(' и продолжается до соответствующего ')'. Например, ERE
(A(B(C)DE)(F)G)
имеет возвращаемое выражения:
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 => ошибка - никакого соответствующего
подвыражения
Флажок "i" указывает, что, соответствие ERE ДОЛЖНО быть выполнено в режиме без учета регистра. Кроме того, когда присутствует флажок "i", любые возвращаемые выражения замены МОГУТ быть нормализованы к строчным буквам.
Первый символ в выражении замены должен использоваться как символ, который разграничивает компоненты выражения замены. В выражении замены должны быть точно три обязательных мест нахождения символа разделителя. Так как необязательные места нахождения символа разделителя интерпретируются как возникновения этого символа, цифры НЕ ДОЛЖНЫ использоваться как разделители. Это позволило бы возвращаемые результат перепутать с литеральными символами. Точно так же, если флаги определены в выражении замены, символ разделителя не должен также быть символом флага.
4. Базовый NAPTR Алгоритм
Поведение и значение флагов и сервисов попадают на вход алгоритма, где каждые выходные данные переписывается на новый ключ, который указывает на другое правило. Этот цикличный алгоритм позволяет записям NAPTR с приращением определять полное правило. Эти возрастающие правила могут быть делегированы, что позволяет другим объектам определять правила так, чтобы одна сущность не должно было подразумевать_все_правила.
Алгоритм начинается со строки и некоторого известного ключа (домена).
Обнаруженые NAPTR записи для таких ключей, но с неизвестными Флажками или несоответствующими сервисами отбрасываются, а остающиеся записи сортируются по полю Order. В пределах каждого значения Order, записи далее сортируются по полю Preferences.
Записи исследуются в отсорованом порядке, пока соответствующая запись не будет найдена. Запись рассматривается на соответствие так и только так:
Первое соответствие ДОЛЖНО быть соответствием, которое используется. Как только соответствие найдено, поле Services исследована на то, действительно ли это правило приводит к желательному результату. Если так, правило применяется к целевой строке. В противном случае процесс останавливается. Домен, который получается из регулярного выражения, потом используется как домен следующего цикла через алгоритм NAPTR. Отметьте, что та же самая целевая строка используется всюду по алгоритму.
Это выполнение чрезвычайно важно, так как это - метод, которым сложные правила прерваются ниже в управляемые делегированные куски. Поле флажков просто определяет, в каком пункте цикл должен остановиться (или другое специализированное поведение).
Так как флажки имеют силу на любом уровне алгоритма, вырожденый цикл никогда не должен образовывать петли, только искать NAPTR и затем останавливаться. Во многих специализированных случаях, это является тем, что необходимо. Разработчики должны знать, что вырожденый цикл не должен стать общим случаем.
5. Относительно того, как NAPTR Использует Записи SRV
Когда тип записи SRV был первоначально определен, это предполагало, что клиент не имеет под рукой определенного имени домена. Клиент хотел бы иметь имя домена скорее в форме его поиска, по сравнения с обычным случаем, когда известно конкретное имя домена, существующего в данное время. То есть, когда клиент хочет знать, есть ли сервер, основанный на HTTP TCP, работающий в конкретном домене, клиент создал бы имя домена _http._tcp.somedomain.com и спросил бы доменную систему имен, существует ли эта запись. Символы подчеркивания используются, чтобы избежать совпадений с потенциальными 'реальными' именами домена.
В случае NAPTR, фактическое имя домена определяется различными полями в записи NAPTR. В этом случае клиент может не посылать запрос, а вместо этого пытается разобраться с информацией, которая может оказаться, существует в записи SRV для этого конкртеного имени домена. В то же время такое использование SRV немного отлично, чем авторы SRV первоначально предназначали, чтобы это не нарушило ни одного из предположений относительно того, что содержит SRV. Кроме того, так как NAPTR явно подробно описывает имя домена, для которого существует SRV, то имя домена ДОЛЖНО использоваться в запросах SRV без преобразований. Любая данная запись NAPTR может привести к имени домена, которое используется для запросов SRV, которые могут или, возможно, не содержит стандартизированные в SRV символа подчеркивания. Приложения NAPTR, которые используют SRV, НЕ ДОЛЖНЫ пытаться понять эти домены или использовать их согласно тому, как спецификация SRV структурирует ее домены запроса
6. Спецификации приложений
Должно быть отмечено, что алгоритм NAPTR - принятие на себя ответственности о том, как NAPTR работает. Причины для перезаписи и ожидаемого вывода и его использования определены в соответствии с документами, которые определяют, для каких приложений запись NAPTR и алгоритм использующийся для него. Любой документ, который определяет такое приложение, должен определить следующее:
7. Примеры
ПРИМЕЧАНИЕ. Это только примеры. Они взяты от продолжающейся разработки и, возможно, не представляют итоги этой работы. Они здесь только по причинам изучения.
7.1 Пример 1
NAPTR был первоначально определен для использования с Открытой Системой Разрешения Единообразного Имени Ресурса. Этот пример детализирует, как специфическая URN (единообразное имя ресурса) использовала бы записи NAPTR, чтобы найти разрешение имен для сервиса.
Рассмотрим пространство имен URN основанное на MIME Content-Id. URN мог бы выглядеть следующим образом:
urn:cid:[email protected]
(Отметьте, что этот пример выбран в целях изучения, и не соответствует схеме CID URL)
Первый шаг в процессе разрешения имен это узнать о пространстве имен CID. Идентификатор пространства имен [3], 'cid', извлечен из URN, предшествующий urn.arpa. Тогда 'cid.urn.arpa' становится первым 'известным' ключем в алгоритме NAPTR. Записи NAPTR для cid.urn.arpa розыскивается и возвращается единственная запись:
cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
Есть только одна запись NAPTR, так что упорядочение записей не проблема. Поле замены пусто, таким образом используется шаблон из поля regexp. Мы применяем это регулярное вырожение ко всему URN, чтобы видеть, соответствует ли это тому, что делает это. Часть \2 подстановки возвращают строку "gatech.edu". Так как область флажков не содержит "s" или "a", поиск не является законченым, и наша следующая проба в DNS для получения большего количества записай NAPTR, где теперь новый домен - 'gatech.edu', и строка - та же самая строка что и прежде.
Заметьте, что правило не извлекает из CID полное имя домена, вместо этого оно предполагает, что CID исходит от хоста и извлекает его домен. В то время как все хосты, типа mordred, могли иметь свой собственный NAPTR, поддержка таких записи для всех машин на громадных сайтов, вроде Georgia Tech будет невыносимым бременем. Групповые символы здесь не являются соответствующими, так как они только возвращают результаты, тогда как в системе уже нет никаких точно соответствующих названий.
Запись, возвращаемая на запрос "gatech.edu" могла бы быть похожа на:
;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
Продолжая пример, заметьте, что значения порядка и поля предпочтений равны во всех записях, таким образом клиент свободен выбрать любую запись. Поле флажков собщает нам, что они являются последними шиблонами NAPTR, которые мы должны смотреть, и после перезаписи (в данном случае простая замена), мы должны искать записи SRV, чтобы получить информацию о хостах, которые могут предоставить необходимый сервис.
При допущение нами представление протокола Z39.50, наш поиск мог бы возвратить:
;; Pref Weight Port Target
_z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu.
IN SRV 0 0 1000 z3950.cc.gatech.edu.
IN SRV 0 0 1000 z3950.uga.edu.
т.е. информирование нас о трех хостах, которые могли фактически быть решением, и предоставление нам порта, который мы должны использовать, чтобы общаться с их сервером Z39.50.
Вспомните, что регулярное выражение использовало \2, чтобы извлечь название домена из CID, и \. для подбора буквеному символу '.', разделяющему компоненты имени домена. С тех пор '\' - символ возврата, буквенные вхождения левой наклонной черты должны сопровождаться другой левой наклонной чертой. Для случая записи cid.urn.arpa, приведенной выше, регулярное выражение вводимое в мастер-файл, должен быть "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". Когда клиент фактически получает код записи, шаблон будет преобразован в "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
7.2 Пример 2
Даже если бы система URN была уже, все еще есть огромное количество URL. Возможно необходимо разработать систему разрешения имен URN, которая также может обеспечить независимость местоположения так же для URL. Это связано с требованием, чтобы URN были предком названий других систем имен, типа Формальные Публичные Идентификаторы ISO (ISO 8879), шифр классификатора библиотеки Конгресса США, ISBNs, ISSNs и т.д.
NAPTR RR могут также использоваться для URL, которые уже были назначены. Предположите, что мы имеем URL для очень популярной части программного обеспечения, которое издатель желает разместить на многочисленных зеркальных сайтах во всем мире:
При использовании правила, определенных для таких приложений мы извлекаем префикс "http", и ищем записи NAPTR для http.uri.arpa. Это могло бы возвратить записи такой формы
http.uri.arpa. IN NAPTR
;; order pref flags service regexp replacement
100 90 "" "" "!http://([^/:]+)!\1!i" .
Это выражение возвращает все между первым двойным слэшом и последующим слэшем или двоеточием. (Мы используем символ '!', чтобы разграничить части выражения подстановки. Иначе мы должны были бы использовать наклонные черты влево, чтобы выйти из передовых слэшей и имели бы регулярное выражение в файле зоны, которое было бы похоже на "/http:\\/\\/([^\\/:]+)/\\1/i".).
Применение этого шаблона к URL извлекает "www.foo.com". Поиск записай NAPTR для него мог бы возвратить:
www.foo.com.
;; order pref flags service regexp replacement
IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com.
IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
Поиск записей SRV для http.tcp.foo.com возвратил бы информацию относительно хостов foo.com, определенных чтобы быть зеркалами этого сайта. Клиент может затем выбрать один из них для пользователя.
7.3 Пример 3
Пример не-URI - приложение ENUM, которое использует записи NAPTR, чтобы отобразить номер телефона e.164 к URI. Чтобы преобразовывать телефонный номер в имя домена по первой итерации, все символы кроме цифр удаляются из номера телефона, все цифры инвертируются, разделители (точки) помещаются между каждой цифрой, и слева помещается строка ".e164.arpa". Например, телефонный номер E.164 "+1-770-555-1212" преобразованный к имени домена было бы таким "2.1.2.1.5.5.5.0.7.7.1.e164.arpa".
Для этого номера телефона примера мы могли бы возвратить следующие записи NAPTR:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:[email protected]!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:[email protected]!" .
Это приложение использует тот же самый флажок 'u' как приложение разрешения имен URI. Этот флажок объявляет, что Правило является законченым и что на выходе находится URI, который содержит информацию, чтобы связаться с этем телефонным сервисом. ENUM также использует тот же самый формат для поля Service за исключением того, что при разрешении имени для использования URI он определяет вместо сервиса 'I2*' сервис 'E2U'. Пример выше показывавет, что для обслуживанию этого телефона из доступных протоколов имеют обыкновение использовать или Протокол Установления Сессии (SIP) или почты SMTP.
8. Формат Пакета DNS
Формат пакета для записи 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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Где:
9. Формат Мастер-файла
Формат мастер-файла соответствуют стандартным правилам FC-1035 [1].
Порядок и предпочтения, будучи 16-битными беззнаковыми целыми числами, должны быть целым числом между 0 и 65535. Флажки и поля Services и Regexp все допустимые . Так как область Regexp может содержать многочисленные наклонные черты влево и таким образом должна быть осторожно обработана. См. Раздел 10 для того, как правильно входить и выходить из регулярного выражения.
10. Совет для администраторов DNS
Будьте осторожны с регулярными вырожениями. Мало того, что они сами по себе трудны в корректности, но еще есть ранее упомянутое взаимодействие с DNS. Любые наклонные черты влево в ругулярном вырожении, чтобы появиться один раз в ответе на запрос, в файле зоны должны быть введены дважды.
Еще более серьезнее то, что необходимость в двойных наклонных чертах влево вероятно не была проверена всеми разработчиками серверов DNS.
Флажок "a" позволяет следующему поиску перейти на записи адресов (A, AAAA, A6), а не записей SRV. Так как в записи NAPTR нет никакого места для спецификации порта, при использовании флажка "A", должен использоваться порт установленный по умолчанию для протокола.
Проект Синтаксиса URN определяет каноническую форму для каждого URN, которая требует % раскодированных символов вне ограниченного набора. Регулярные выражения ДОЛЖНЫ быть написаны, чтобы работать на такой канонической форме. Так как международные наборы символов закончатся с обширным использованием % раскодированных символов, регулярные выражения, работающие на них по существу будет невозможны читать или писать вручную.
11. Примечания
12. Рассмотрения IANA
Единственная регистрационная функция, которая возлагается на IANA, - для значений, которые стандартизированы для полей Services и Flags. Расширять допустимые значения поля Flags помимо того, что определено в этом документе, требует издание спецификации, которая одобрена IESG.
Значения для поля Services будут определены приложением, которое использует записи NAPTR. Эти значения должны быть определены в изданной спецификации и одобрены IESG.
13. Соображения безопасности
Взаимодействия с DNSSEC в настоящее время изучаются. Ожидается, что записи NAPTR будут состыкованы с записями SIG, как только работа DNSSEC будет развернута.
Правила перезаписи делают идентификаторы из другого правила имен подвержаны тем же самым нападениям как обычные имена домена. Так как они не были легко доступны прежде, это может или, возможно, не считать проблемой.
Регулярные выражения должны быть осмыслено проверены, не вслепую кое к чему-то подобного PERL.
Этот документ обсудил способ определения местонахождение сервиса, но не обсудил никакой детали того, как с тем сервисом осуществляется коммуникация. Есть существенные вопросы по безопасности, относительно коммуникаций с сервисом. Такие вопросы - вне компетенции данного документа, и нужно обратиться к спецификациями для конкретных протоколов коммуникации.
14. Подтверждения
Редакторы хотели бы благодарить Кита Моора за все его консультации в время работы над этим документом. Мы также хотели бы благодарить Пола Викси за его помощь в проверке нашей разработки, и его ответы на наши вопросы. Наконец, мы хотели бы признать наш огромный интеллектуальный долг перед участниками ряда Knoxville встреч, а так же участниками рабочих групп URI и URN.
Ссылки
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[8] 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.
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
Адреса Авторов
Michael Mealling
Network Solutions, Inc.
505 Huntmar Park Drive
Herndon, VA 22070
US
Phone: +1 770 921 2251
EMail: [email protected]
URI: http://www.netsol.com
Ron Daniel
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA 94107
US
Phone: +1 415 222 0100
EMail: [email protected]
URI: http://www.datafusion.net
Полная Формулировка Авторского права
Copyright © The Internet Society (2000). All Rights Reserved.
Copyright © Перервод на русский язык. Voipx Inc. 2007
Этот документ и переводы этого могут быть скопированы и доставлены другим, и производные работы, которые комментируют или иначе объясняют это или помогают в его выполнении, могут быть готовы, скопированы, изданы и распределены, полностью или частично, без ограничения любого вида, при условии, что вышеупомянутое уведомление об авторском праве и этот параграф включены во все такие копии и производные работы. Однако, этот сам документ не может быть изменен никогда, типа, удаляя уведомление об авторском праве или справочную информацию на интернет-Общество или другие интернет-организации, кроме как необходимо ради развития интернет-стандартов, когда процедуры для авторских прав, определенных в интернет-процессе Стандартов должны сопровождаться, или как требуется переводить это в языки кроме английского языка.
Ограниченные разрешения, предоставленные выше являются бессрочными и не будут отменяться интернет-Обществом или его наследниками или правопреемниками.
Этот документ и информация, содержавшаяся здесь обеспечиваются на основе "КАК ЕСТЬ" и ИНТЕРНЕТ-СООБЩЕСТВО И ЦЕЛЕВАЯ ГРУППА РАЗРАБОТЧИКОВ ИНТЕРНЕТ ПРОЕКТИРУЯ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНО ИЛИ НЕ ЯВНО, ВКЛЮЧЕННЙ, НО НЕ ОГРАНИЧЕННЫЙ ЛЮБОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ ЗДЕСЬ НЕ БУДЕТ НАРУШАТЬ НИКАКИХ ПРАВ ИЛИ ЛЮБЫХ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ ВЫСОКОГО СПРОСА ИЛИ ЗДОРОВЬЯ В ЧАСТНЫХ ЦЕЛЯХ.
Подтверждение получения
Финансирование для функции редактирования RFC в настоящее время обеспечивается Интернет-Сообществом.
Перевод Соколов О.В.