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: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-последовательности где-нибудь в другом месте). Выражение «^.*$» в регулярном выражении означает «начало, любое число любых символов и завершение» (другими словами, под этот шаблон подходит любая строка данных) изменено на "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).