NAPTR

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Запись Ресурсов Указателей Авторитетных Имен (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:information@pbx.example.com!i" .
 IN NAPTR 102 10 "u" "E2U+email" "!^.*$!mailto:information@example.com!i"  .

Из этих двух записей, первое имеет значение Order равное 100, которое меньше чем 102, таким образом оно выбирается первым. Preference равное 10 не имеет значение, поскольку никакие другие правила не имеют Order равный 100. Флажок «u» показывает оконечное правило в приложениях ENUM и URI, таким образом вывод этой перезаписи будет результатом, который мы ищем. См. RFC 2915 для списка допустимых флажков.

Если мы поддержим сервис, определяемый ключом «E2U+sip», то мы не будем продолжать проверять другие правила с более высокими значениями Order. Регулярное выражение перезаписи "!^.*$!sip:information@pbx.example.com!i" находит выходное значение, преобразовывая наш оригинальный запрос 2.1.2.1.5.5.5.0.7.7.1.e164.arpa в sip:information@pbx.example.com. В регулярном выражении, восклицательный знак '!' будет нашим разделителем (мы избегаем использования '/' и '\', потому что они могут интерпретироваться как escape-последовательности где-нибудь в другом месте). Выражение «^.*$» в RE (регулярном выражении) говорит, что «старт вначале, включая любые символы и заканчивается в конце» (другими словами, все) изменено на "sip:information@pbx.example.com", и вариант 'i' игнорируется. (Внимательные читатели заметят, что 'i' не имеет значения, учитывая использование «.*»). Знакомые с регулярными выражениями Perl, эквивалентное регулярное выражение могли бы написано как "s/^.*$/sip:information@pbx.example.com/i". Так что получающимся URI будет являться "sip:information@pbx.example.com". Если бы мы не поддерживали SIP, то мы эффективно вернулись бы опять к правилу, приводящему к "mailto:information@example.com".

Сноски[править | править вики-текст]

См.также[править | править вики-текст]

EDNS также используется в выполнении NAPTR, поддерживая более длинные пакеты DNS, которые могут потребоваться при использовании кратных записей NAPTR.

Внешние связи[править | править вики-текст]

Оригинальные BIND, поддерживающие NAPTR, не будут поддерживать djbdns без установки патча или использования записей generic tinydns (RFC 3403).