NAPTR

NAPTR помещает Авторизованные Именные Ссылки и является новейшим типом записи DNS, который поддерживает перезапись, базируемую на регулярных выражениях. Несколько записей NAPTR могут образовать цепочку, создаваемую вместо довольно сложных перезаписывающих правил URI. До достижения предельного условия запись может пройти любое число перезаписей.

Например, после перевода телефонного номера +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".

Сноски

• RFC 2915 - was previously the specification for NAPTR (superseded by RFC 3403 below)
• RFC 3401 - DDDS (Dynamic Delegation Discovery System) - uses NAPTR records
• RFC 3403 - DDDS Part 3 (DNS) now specifies and describes NAPTR records
• Additional background on NAPTR in the context of ENUM can be found at the NIC.at site http://enum.nic.at/documents/Diverse/Background_to_NAPTR.html
• IANA provide a registry for ENUM services
• Перевод RFC 2915. Записи DNS типа NAPTR
• Перевод файла README.enum из Asterisk v1.2

См.также

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

Внешние связи

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