NAPTR (NAPTR)
Name Authority Pointer (NAPTR) — один из видов записи ресурса в системе доменных имён в Интернете.
NAPTR-записи чаще всего используются для приложений интернет-телефонии, например при отображении серверов и адресов пользователей в протоколе установления сеанса (SIP). Несколько NAPTR-записей в сочетании со служебными записями (SRV) позволяют создавать цепь записей для формирования сложных правил перезаписи, которые используются для создания дополнительных частей доменного имени или идентификаторов (URI).
Код DNS для записи NAPTR — 35.
Обоснование
[править | править код]Универсальные имена ресурсов (URN) являются подмножеством универсальных идентификаторов ресурсов (URI) и используются для абстрактных идентификаторов, таких как имя человека или его номер телефона. Для имен URN необходимо соответствующее сопоставление с ресурсами какого-либо типа. Имена URL часто используются для описания ресурсов, таких как компьютерное имя хоста или локальный файл. NAPTR запись помогает в стандартизации новых имен URN. NAPTR обозначает карту между комбинацией имен URN, URL-адресов и простых доменных имен, а также позволяет клиентам сети протоколы доступные для связи с подключенного ресурса. Каждая запись NAPTR содержит имя службы, набор флагов, правила регулярных выражений, значения заказа, предпочтение и шаблон замены. Несколько записей могут быть соединены вместе в каскаде перезаписи идентификаторов URI детерминированными способами. Эти каскадные правила были стандартизованы в RFC2915 и RFC3403.
Примеры
[править | править код]Например, после перевода телефонного номера +1-770-555-1212 в URI 2.1.2.1.5.5.5.0.7.7.1.e164.arpa как описано в E.164 и ENUM, DDDS используется, чтобы преобразовать это используя правила перезаписи, заключенные в записях NAPTR. Конфигурация BIND для записей возвращает из запроса для 2.1.2.1.5.5.5.0.7.7.1.e164.arpa возможные варианты:
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!i" . IN NAPTR 102 10 "u" "E2U+email" "!^.*$!mailto:[email protected]!i" .
Из этих двух записей, первое имеет значение Order равное 100, которое меньше чем 102, таким образом оно выбирается первым. Preference равное 10 не имеет значения, поскольку никакие другие правила не имеют Order равный 100. Флажок «u» показывает оконечное правило в приложениях ENUM и URI, таким образом вывод этой перезаписи будет результатом, который мы ищем. См. RFC 2915 для списка допустимых флажков.
Если сервер поддерживает сервис, определяемый ключом «E2U+sip», то он не будет продолжать проверять другие правила с более высокими значениями Order. Регулярное выражение для перезаписи строки "!^.*$!sip:[email protected]!i" находит выходное значение, преобразовывая оригинальный запрос 2.1.2.1.5.5.5.0.7.7.1.e164.arpa в sip:[email protected]. В приведённом регулярном выражении, восклицательный знак '!' будет разделителем (с исключением использования '/' и '\', потому что они могут интерпретироваться как escape-последовательности где-нибудь в другом месте). Выражение «^.*$» в регулярном выражении означает «начало, любое число любых символов и завершение» (другими словами, под этот шаблон подходит любая строка данных) изменено на "sip:[email protected]", и вариант 'i' игнорируется. (Внимательные читатели заметят, что 'i' не имеет значения, учитывая использование «.*»). В стандарте регулярных выражений Perl эквивалентный шаблон можно было быть записать так "s/^.*$/sip:[email protected]/i". В результате будет получен URI "sip:[email protected]". Если бы сервер не поддерживал SIP, то при обработке произошёл возврат правилу, приводящему к "mailto:[email protected]".
См. также
[править | править код]EDNS также используется в выполнении NAPTR, поддерживая более длинные пакеты DNS, которые могут потребоваться при использовании кратных записей NAPTR.
Внешние связи
[править | править код]Оригинальные BIND, поддерживающие NAPTR, не будут поддерживать djbdns без установки патча или использования записей generic tinydns (RFC 3403).
В статье не хватает ссылок на источники (см. рекомендации по поиску). |