Summary

  • RFC 3405 made a registered URI scheme or URN namespace, its stable specification and its recognized authority prerequisites for putting NAPTR rules in uri.arpa. or urn.arpa.. DNS syntax alone did not grant delegation power.
  • Shared-zone records were expected to have extremely long TTLs. Rules likely to change belonged in a shorter-lived delegated zone behind a stable first hint, so global bootstrap stability and local operational agility could coexist.

A long cache lifetime is usually described as an inconvenience. RFC 3405 treated it as an architectural material. If a globally shared resolution entry might be cached for years, the entry should not carry the rule most likely to change. It should carry a stable instruction for finding the authority that changes the rule.

Published as Best Current Practice 65 in October 2002, RFC 3405 completed the five-part Dynamic Delegation Discovery System series. RFC 3401 introduced the framework, RFC 3402 defined the algorithm, RFC 3403 placed rules in DNS NAPTR records, RFC 3404 specified URI and URN resolution services, and RFC 3405 governed assignments in uri.arpa. and urn.arpa..

The last document was not merely registry paperwork appended to a technical design. It decided who could place the first rule in a globally shared DNS space, how that authority was proved and which part of the resolution path was allowed to move quickly. Those are executable properties of the system.

For URI resolution, a scheme such as http supplied the first key under uri.arpa.. For URNs, the urn rule in uri.arpa. extracted the namespace identifier and transferred lookup to the corresponding key under urn.arpa.. The shared zone therefore sat at a high-leverage point: a small record could redirect an entire class of identifiers toward its next delegation path.

RFC 3405 refused to let the NAPTR registration create the identifier authority it claimed to represent. A URI scheme had to be registered and backed by a stable specification first. A URN Namespace Identifier likewise had to complete its own registration process. The resolution hint followed the identifier's legitimacy; it did not confer legitimacy backwards.

That ordering prevented two different shortcuts. One was procedural: using an urn.arpa. record to circumvent review of a new namespace. The other was operational: inserting a URI rule that delegated DNS-based identifiers to someone other than the holder of the domain name embedded in those identifiers. A technically valid regular expression could still be an authority hijack.

Review therefore examined correctness and technical soundness, consistency with the published scheme, and the ownership boundary of DNS-based URIs. When a scheme or namespace specification was controlled outside the IETF, a later addition or modification also needed approval from its owner or maintainer. Expert review did not substitute for that approval; the two receipts answered different questions.

For a URN namespace, the owner boundary extended across all NAPTR records for the NID even if one record affected only a subset of the assigned space. A narrow-looking rule could still alter the namespace's resolution surface. Scope in the regular expression did not erase the authority of the namespace maintainer.

The registration template exposed the provenance chain. It named the Key, the recognized Authority and the actual DNS Records. This was more than a zone-file fragment. The key identified the globally shared slot, the authority identified who was entitled to request it, and the records stated the executable delegation.

The original submission process used public mailing lists and a two-week period for objections. But the objection scope was deliberately limited. Review at this stage could address harm to the shared zone or DNS generally; it was not an opportunity to reopen the merits of the already sanctioned scheme or namespace. Architectural layers had different forums, and an objection had to arrive at the layer that owned it.

IANA served as the registration authority and operator of the zones and lists. Central operation did not mean central authorship of every resolution rule. Scheme and namespace authorities supplied entitlement and specifications; reviewers checked the shared DNS impact; IANA published the accepted entry; delegated operators ran the changing rules beyond it.

The most revealing instruction concerned TTL. RFC 3405 expected records in uri.arpa. and urn.arpa. to have extremely long lifetimes, perhaps measured in years, in order to reduce query load on the common zones. A record cached for that long was unsuitable for policy that needed frequent adjustment.

The prescribed answer was temporal delegation. Keep a stable NAPTR record in the common zone, then point it to another DNS zone whose TTL could be much shorter. The root hint said where the changing authority lived; the delegated zone contained the current rule set. One layer optimized for global stability and low load, the other for operational change.

This separation resembles a durable pointer to a mutable document, but the DNS details make it stricter. A cache may retain the first pointer and independently refresh the delegated rules. A change in the downstream zone cannot revoke an already cached first hint, and a change in the first hint may take a very long time to become universal. Operators therefore have to record which layer changed, which TTL governed observation and which authority signed each step.

Not every scheme needed an extra dynamic zone. Some identifier syntax already fixed the next key. An HTTP URI carries a host, so a stable rule could extract that host and use it for the next lookup. Other namespaces allowed more flexible delegation and were better served by a stable pointer to a separately administered rule zone. The placement of the next key was part of the scheme's control geometry.

The urn rule demonstrated nested governance. A generic URI first entered uri.arpa. because URN is a URI scheme. That stable rule extracted the namespace identifier, and the namespace-specific decision then occurred under urn.arpa.. The transition preserved a common entry point without forcing every URN namespace into one operational rule.

Two verified technical errata matter to anyone reconstructing the examples. Errata 2687 and 2688 correct both published regular expressions from back-reference \2 to \1; each expression contains only one capture group. The printed forms are invalid. Historical authority does not make a broken example executable, and an implementation record should state whether the verified corrections were applied.

The standard's eligibility language also aged. RFC 3405 originally allowed only URI schemes in the “IETF tree,” following RFC 2717. Later URI registration practice abolished scheme-name trees. A 2011 erratum that tried to repair the normative rule was correctly rejected: changing eligibility required a new standards document, not an editorial patch.

RFC 8958 supplied that update in 2020. It removed the IETF-tree requirement and now requires that a URI scheme have permanent registration under BCP 35, currently RFC 7595, before receiving a uri.arpa. assignment. The change repaired the gate while preserving the deeper sequence: establish the identifier space, then authorize its shared resolution hint.

The current IANA URI Schemes registry distinguishes permanent, provisional and historical registrations; current URI.ARPA eligibility selects permanent schemes rather than every name that appears in the registry. The current URN Namespaces registry follows RFC 8141's expert-review procedures. Registry presence and shared-zone publication remain separate events with different evidence.

IANA's present .arpa documentation still lists uri.arpa for DDDS URI resolution under RFCs 3405 and 8958 and urn.arpa under RFC 3405. That continuity proves an assigned infrastructure purpose, not that every possible scheme or namespace has deployed a NAPTR rule or that any returned service is working.

Security followed from concentration. The two shared zones were obvious denial-of-service targets, and spoofed entries could redirect delegation paths. DNS signing could authenticate published data, but it could not establish that a requester had the scheme maintainer's approval, that the downstream operator honored the current specification or that a consumer received the intended resource.

A useful registration and runtime receipt therefore spans more than a DNS answer: scheme or NID status, stable specification, recognized authority, owner approval, submission and review dates, permitted objections, IANA acceptance, published record, DNSSEC status, long TTL, delegated key, downstream authority, shorter TTL, rule change, cache observation, selected rule and consumer outcome.

Lu Heng's Minimum Initial Specification principle explains the two-speed design. The global layer standardized the smallest durable handoff; future operational choices stayed behind a delegated boundary. Running-Code Primacy supplies the proof: inspect the live records, apply the verified errata, change only the downstream zone, observe both TTLs from independent caches, and confirm that authority follows the registered maintainer rather than whoever can compose valid NAPTR syntax.

RFC 3405 made stability a placement decision. The first hint could remain slow because it did not pretend to be the current resolver rule. The system stayed adaptable because change was localized, attributed and given its own clock.

Sources