Кратко

  • RFC 3405 требовал заранее зарегистрированную схему URI или пространство URN, стабильную спецификацию и признанные полномочия до публикации NAPTR в uri.arpa. или urn.arpa.. Правильный синтаксис DNS не создавал права.
  • Общие зоны должны были иметь очень долгие TTL. Меняющиеся правила следовало поместить в делегированную зону с меньшим TTL за стабильной первой подсказкой.

Долгий TTL часто считают эксплуатационной помехой. RFC 3405 превратил его в материал архитектуры. Если глобальная запись остаётся в кэшах годы, ей не следует содержать самую подвижную политику; она должна устойчиво указывать на того, кто эту политику меняет.

Документ вышел как BCP 65 в октябре 2002 года и завершил серию DDDS. RFC 3401 представил систему, RFC 3402 алгоритм, RFC 3403 правила NAPTR в DNS, RFC 3404 службы URI/URN, а RFC 3405 назначения в uri.arpa. и urn.arpa..

Это было не бюрократическое приложение. Оно определяло, кто вправе записать первый шаг в глобальном DNS-пространстве, как доказать полномочия и какой слой может быстро меняться. Регистрация стала частью исполняемого пути.

Схема URI давала первый ключ в uri.arpa.. Для URN запись urn извлекала идентификатор пространства и передавала поиск в urn.arpa.. Маленькая запись на входе могла перенаправить целый класс идентификаторов.

NAPTR не мог создать полномочия, которые представлял. Схема нуждалась в предварительной регистрации и стабильной спецификации; NID — в собственном завершённом процессе. Подсказка следовала за легитимностью пространства, а не даровала её задним числом.

Порядок не позволял обойти проверку нового NID через urn.arpa. и запрещал передать DNS-основанный URI стороне, не владеющей встроенным доменным именем. Синтаксически правильное выражение всё равно могло похищать власть.

Проверка охватывала техническую корректность, соответствие спецификации и границу собственности DNS. Если спецификация поддерживалась вне IETF, последующие добавления или изменения требовали согласия владельца либо сопровождающего. Экспертное заключение и разрешение были разными квитанциями.

Для NID контроль распространялся на все NAPTR, даже если правило затрагивало лишь часть пространства. Узкий шаблон не отменял власть сопровождающего.

Шаблон содержал Key, Authority и Records. Key выбирал глобальное место, Authority называл уполномоченного заявителя, Records описывал исполняемое делегирование. Это была цепь происхождения, не просто фрагмент зоны.

Изначально использовались открытые списки и две недели для возражений. Их область ограничивалась влиянием на зону или DNS; достоинства уже санкционированной схемы обсуждались ранее. Каждый слой имел свой форум.

IANA управляла зонами и списками, но не сочиняла все правила. Власти идентификатора давали право и спецификацию, эксперты оценивали общий риск, IANA публиковала, делегированные операторы меняли рабочую часть.

Главная инструкция касалась времени. Для снижения нагрузки TTL общей зоны мог измеряться годами. Часто меняющейся политике не место непосредственно на такой поверхности.

Решением стало временное делегирование. Стабильный NAPTR в общей зоне указывал на другую зону с коротким TTL. Верхний слой обеспечивал устойчивость, нижний — оперативность. У одного пути появлялись двое часов.

Кэш мог сохранять первый указатель и обновлять последующие правила. Изменение снизу не отзывает старую подсказку; изменение сверху распространяется долго. Аудит должен связывать каждую версию с уровнем, TTL и властью.

Не каждой схеме нужна динамическая зона. URI HTTP уже содержит хост, который извлекает стабильное правило. Гибкие пространства выигрывают от отдельной зоны. Расположение следующего ключа формирует геометрию управления.

Правило urn показывало вложенное управление: URN входил через uri.arpa., отдавал NID и переходил к решению пространства под urn.arpa.. Общий вход не унифицировал локальную политику.

Две подтверждённые технические ошибки меняют исполнение. Errata 2687 и 2688 заменяют \2 на \1, потому что в каждом примере одна группа захвата. Напечатанные выражения недействительны и не должны копироваться в рабочую конфигурацию.

Условие допуска тоже устарело. RFC 3405 требовал “IETF tree” из RFC 2717, но деревья имён схем отменили. Попытку изменить норму через erratum отвергли: нужен новый RFC.

RFC 8958 выполнил обновление в 2020 году: убрал дерево и потребовал постоянную регистрацию по BCP 35, ныне RFC 7595. Ворота изменились, последовательность сохранилась: сначала уполномоченное пространство, затем общая подсказка.

Современный реестр IANA различает постоянные, предварительные и исторические схемы; одного присутствия недостаточно для URI.ARPA. Реестр URN Namespaces следует RFC 8141. Регистрация имени и публикация в зоне — разные события.

Текущая страница .arpa относит uri.arpa к RFC 3405/8958, а urn.arpa к RFC 3405. Это доказывает инфраструктурное назначение, но не всеобщее развёртывание NAPTR и не успех разрешателя.

Общие зоны концентрировали риски отказа и подмены. DNSSEC удостоверял данные DNS, но не согласие сопровождающего, поведение делегированной стороны или конечный ресурс.

Полная квитанция хранит статус схемы/NID, спецификацию, полномочия, согласие, заявку, проверку, принятие IANA, запись, DNSSEC, долгий TTL, ключ, нижнюю власть и TTL, изменение, наблюдение кэша, выбранное правило и результат.

Минимальная начальная спецификация Lu Heng объясняет две скорости: глобально нормировать лишь минимальную долговечную передачу, а будущие решения локализовать за ней. Приоритет работающего кода требует проверить живой DNS, применить errata, изменить только нижнюю зону, сравнить TTL и убедиться, что власть следует зарегистрированному сопровождающему, а не автору NAPTR.

RFC 3405 сделал стабильность выбором расположения. Первая подсказка менялась медленно, потому что не притворялась текущим правилом. Адаптация оставалась возможной: изменение было локальным, атрибутированным и имело собственные часы.

Источники