要約

  • RFC 3405 は、URI scheme または URN 名前空間、その安定仕様、認められた権限が先に存在することを、uri.arpa./urn.arpa. の NAPTR 公開条件とした。正しい DNS 構文だけでは委任権にならない。
  • 共有ゾーンの TTL は年単位にもなるほど長い想定だった。変動する規則は短い TTL の委任先へ移し、安定した第一ヒントの背後で運用する。

長い TTL は更新の邪魔と見なされやすい。RFC 3405 は逆に設計材料とした。世界中のキャッシュに何年も残る入口には、最も変わりやすい方針を書かない。方針を更新する権限の所在だけを耐久的に示す。

2002 年 10 月に BCP 65 として発行された文書は、DDDS 五部作の最後だった。RFC 3401 は全体、RFC 3402 はアルゴリズム、RFC 3403 は DNS NAPTR、RFC 3404 は URI/URN 解決サービス、RFC 3405 は uri.arpa. と urn.arpa. の割当を担った。

最後の一部は事務的付録ではない。世界共通 DNS 空間の最初の規則を誰が書けるか、その権限をどう証明するか、どの層なら速く変更できるかを決めた。登録手続が実行経路そのものを左右した。

URI scheme は uri.arpa. の第一キーになる。URN はまず同ゾーンの urn 規則で名前空間識別子を取り出し、urn.arpa. のキーへ進む。小さな入口レコードが、識別子群全体の次経路を変え得た。

NAPTR 登録は、それが代表すると称する権限を自ら作れない。scheme は登録済みで安定仕様を持ち、URN NID は自身の登録過程を終えていなければならない。解決ヒントは識別子空間の正当性に従うのであり、逆向きに正当化しない。

この順序は、urn.arpa. を使った NID 審査回避と、DNS ベース URI を埋込ドメインの保有者以外へ委任する乗っ取りを防いだ。正規表現が技術的に妥当でも、権限の移転は不当になり得る。

審査は技術的健全性、公開仕様との整合、DNS 名の所有境界を見る。仕様が IETF 外で管理される場合、後日の追加や変更には所有者・保守者の承認も必要だった。専門審査と所有者承認は別の証拠である。

URN NID では、一規則が割当空間の一部だけに効く場合でも、全 NAPTR に保守者の権限が及ぶ。パターン範囲を狭くしても名前空間の統治は回避できない。

申請テンプレートは Key、Authority、Records を並べた。Key は世界共通の枠、Authority は申請資格、Records は実行可能な委任を表す。単なるゾーンファイル断片ではなく由来の受領証だった。

当初の手続は公開メーリングリストと二週間の異議期間を使った。ただし異議はゾーンまたは DNS への影響に限られた。既に承認された scheme/NID の是非は、その前段のフォーラムで争う。各層には固有の決定場所があった。

IANA はゾーンとリストを運用したが、全規則の作者ではない。scheme/名前空間権限者が資格と仕様を出し、審査者が共有 DNS への影響を確認し、IANA が掲載し、委任先運用者が変動規則を保守した。

核心は時間だった。共通ゾーンの負荷を減らすため、レコード TTL は非常に長く、年単位も想定された。頻繁に変える政策をそのキャッシュ面へ直接置くのは不適切である。

そこで時間的委任を使う。共通ゾーンには安定 NAPTR を残し、短い TTL の別 DNS ゾーンへ向ける。上層は大域安定と低負荷、下層は運用変更を担当する。一つの経路に二つの時計が生まれる。

再帰キャッシュは第一ポインターを保持したまま下流規則だけ更新できる。下流変更は古い第一ヒントを撤回せず、第一ヒント変更は広がるまで長い。監査は変更層、観測時の TTL、各段階の権限を分ける必要がある。

すべての scheme が動的ゾーンを要するわけではない。HTTP URI は構文中にホストを持ち、安定規則が次キーとして抽出できる。柔軟な委任を持つ名前空間は短 TTL ゾーンへ渡す方がよい。次キーの所在が制御構造を決める。

urn 規則は入れ子の統治を示した。URN は URI scheme として uri.arpa. に入り、NID を抽出後、urn.arpa. で名前空間固有判断へ移る。共通入口は個別政策を均一化しなかった。

二件の Verified 技術正誤は実行に直結する。2687 と 2688 は、捕捉群が一つしかない二つの例で \2 を \1 に直す。印刷形は無効であり、稼働設定へコピーしてはならない。

資格規則も老朽化した。RFC 3405 は RFC 2717 の “IETF tree” を条件にしたが、scheme 名ツリーは後に廃止された。erratum で規範を変える提案は、新 RFC が必要として拒否された。

RFC 8958 が 2020 年に正式更新し、ツリー条件を削除して BCP 35、現在の RFC 7595 による恒久登録を必須とした。入口条件は変わっても、識別子空間を先に認可し共有ヒントを後に置く順序は維持された。

現在の IANA URI Schemes は恒久、暫定、歴史的を区別するため、掲載だけで URI.ARPA 対象にはならない。URN Namespaces は RFC 8141 の審査に従う。名前登録と共通ゾーン公開は別事件である。

現在の IANA .arpa ページも uri.arpa を RFC 3405/8958、urn.arpa を RFC 3405 の用途として掲げる。これはインフラ用途を証明するが、全 scheme の NAPTR 配備やサービス成功を証明しない。

共通ゾーンは DoS と委任先を変える偽装の標的になる。DNSSEC は公開 DNS データを認証できても、保守者承認、下流の仕様遵守、最終資源の真正性までは証明しない。

完全な受領証には scheme/NID 状態、安定仕様、認定権限、所有者承認、申請、審査日、異議範囲、IANA 受理、公開レコード、DNSSEC、長 TTL、委任キー、下流権限と短 TTL、変更、キャッシュ観測、採用規則、消費結果が必要である。

Lu Heng の最小初期仕様は二速度を説明する。世界層では最小で耐久的な引き渡しだけを標準化し、将来判断を局所境界の後ろへ置く。動くコード優先なら、実レコードを観測し、正誤を適用し、下流だけ変更して二つの TTL を比較し、権限が NAPTR を書ける人物ではなく登録保守者に従うか検証する。

RFC 3405 は安定を配置の選択にした。第一ヒントが遅く変わるのは、現在規則を装わないからである。変更は局所化され、帰属と固有の時計を持つことで可能になった。

出典