要約
- RFC 9526 では Homenet Naming Authority が公開ゾーンを作成し、DNSSEC の秘密鍵を家庭側に保持する。一方、Distribution Manager と公開権威サーバーがインターネットへの配布を担う。
- 相互 TLS は制御・同期チャネルの相手を認証するが、ドメイン所有、親 DS の反映、全公開ノードへの最新シリアル配布、外部検証の成功までは証明しない。
- 公開権威を主張するなら、資格、署名世代、転送、配布、親委任、外部検証、撤回を一つの世代番号で結んだ証跡が要る。
任意の一台が古ければ「公開済み」は曖昧になる
ある家庭の HNA がシリアル 108 のゾーンを署名したとする。Distribution Manager は AXFR を終え、二つの公開拠点も 108 を返した。しかし三つ目の拠点は 107 のまま、親ゾーンの DS は交換前の鍵を参照している。家庭内の管理画面はすべて成功を示すかもしれない。
ここで、どの表示も必ずしも虚偽ではない。署名は成功した。転送も成功した。いくつかのサーバーは新しい版を公開した。ただし、「この公開名は現在、意図した権威の下で世界から検証できる」という複合命題は成立していない。
RFC 9526 が示す本質は、単純化された設定手順よりも権限の分割にある。家庭側は公開する名前を選び、ゾーンを作り、署名する。外部事業者はゾーンを取得し、公開サーバーへ広げる。レジストラまたは親運用者は DS によって信頼を接続する。再帰リゾルバーはその結果を観測する。一つの成功通知に、これらすべてを代表させてはならない。
home.arpa は公開用の在庫表ではない
RFC 9526 の対象は登録済みドメイン配下の Public Homenet Zone である。家庭内の home.arpa に置かれる Homenet Zone を、そのままインターネットへ複製する仕組みではない。ローカル名前空間は非公開であり、この公開手順の範囲外だ。
HNA は DHCP、mDNS、UPnP、PCP、手動設定などから候補を得られる。それでも公開は自動発見の副作用ではなく、方針に基づく選択でなければならない。リンクローカルアドレスは公開ゾーンに適さない。ULA やプライベート IPv4 は VPN 利用者に意味を持つ場合があるが、名前が解決できることと一般のインターネットから到達できることは別である。
したがって最初の証跡は、転送ログではなく選択記録だ。どの名前とアドレスを含め、何を除外し、どの方針版を使い、誰が承認したか。最終ゾーンだけを残すと、機器名の露出が意図的だったのか、発見機能から紛れ込んだのか、廃棄後に残ったのかを説明できない。
秘密鍵を持つ者と、応答を届ける者
公開ゾーンの全内容は HNA が作成する。HNA は DNSSEC で署名し、鍵素材を管理する。RFC 9526 のアーキテクチャには、DNSSEC の秘密鍵を Distribution Manager へ渡す手順がない。
これはアウトソーサーの権限を限定する。DM が受け取るのは署名済みの主張であり、家庭になり代わって新しい真正な主張を作る能力ではない。配布系が侵害されても、新しい正当な署名を勝手に生成することはできない。
しかし、署名鍵を家庭に残すだけで公開を完全に支配できるわけでもない。HNA は隠れプライマリであり、十分な保護なしに公開 NS へ載せるべきではない。通常の公開問い合わせへ応答するのは DOI の権威サーバーである。DM は新しい版を取得しないことも、古いがまだ署名有効な版を配り続けることもできる。
ゆえに「署名済み」と「公開中」は別の運用状態である。前者にはシリアル、内容ハッシュ、DNSKEY、署名有効期間が必要だ。後者には、どの公開インスタンスがいつその版を返したかが必要になる。
二つの TLS チャネルは役割が逆になる
制御チャネルでは HNA がクライアントとして DM に接続する。委任、DS、同期先に関する情報を交換し、双方を TLS で認証する。HNA は DM の識別情報と接続先を知り、DM は HNA の識別情報と Registered Homenet Domain を対応付ける。
同期チャネルでは接続の向きが変わる。DM が TLS クライアント、HNA がサーバー兼隠れプライマリとなり、AXFR または IXFR でゾーンを取得する。NOTIFY は更新確認を早めるが、DM は SOA のタイマーに従って自律的にも確認する。
同じ IP とポートを使ったとしても、二つのチャネルは同一ではない。相互 TLS が証明するのは、所定の信頼設定でそのセッションの相手を認証したことだ。登録ドメインを法的・運用上支配していること、期待したシリアルを取得したこと、公開ノードまで配布したことは別の証明を要する。
認証を権限と読み替え、権限を実行と読み替え、実行を最終結果と読み替えると、自動化は証拠の範囲を超えてしまう。チャネルごとの役割を保存することが、その越境を防ぐ。
DM より先の配布は事業者固有になる
DM は隠れセカンダリとしてゾーンを取得し、DOI の公開権威サーバーへ送る。この Distribution Channel に唯一の規範的方式はない。AXFR、REST、データベース複製、その他の仕組みを使える。
柔軟性は既存 DNS 基盤への導入を容易にする。一方で、HNA から DM までの成功をエッジ全体の成功と誤認しやすくなる。複数地域、任意経路、異なるソフトウェア版があれば、一部だけが遅れることは十分あり得る。
必要なのは事業者固有の配布証跡だ。DM が受理したシリアルとハッシュを記録し、予定された公開インスタンスごとに SOA、DNSKEY、代表的 RRset を確認する。単一の任意経路アドレスへの問い合わせは、背後の全ノードを列挙しない。複数地点からの観測も標本であって、完全な内部台帳ではない。
それでも主張は狭く正確にできる。「DM は世代 108 を受理した」「この観測窓では四地点が 108、一本が 107 を返した」。この表現なら、未確認の範囲を成功に塗り替えずに済む。
親 DS への NOERROR は委任完成の領収書ではない
HNA は KSK のハッシュを DS RRset として渡す。DOI がレジストラでもあるなど、親ゾーンを更新できる関係を持つ場合、DM はその DS を親へ反映できる。要求を受理した DM は NOERROR を返し、親更新を行うと約束する。
この応答が確定するのは DM の受付までだ。レジストリ処理の完了、親ゾーンの実データ、キャッシュの更新、外部バリデータの結果は含まれない。RFC の用語が「commitment」であるのは重要で、約束と観測は同じではない。
安全な委任には、子ゾーンの署名、親の正しい DS、そして検証可能な連鎖がそろう必要がある。HNA が安全な委任を手配できない場合でも、ゾーン自体は署名しなければならない。つまり署名の存在は、親への接続を保証しない。
提出 DS、DM 応答、親ゾーンの読み戻し、独立した検証結果を別々に保管するべきだ。「DNSSEC 有効」という一つの値に潰すと、ロールオーバー時にどこで連鎖が切れたか分からなくなる。
ドメイン所有権は前段の統治問題である
DOI は HNA が Registered Homenet Domain を所有すると確信できなければ、公開ゾーンを提供してはならない。ただし RFC 9526 は、その所有証明を範囲外に置く。
DOI とレジストラが同じなら、顧客アカウントと契約が根拠になり得る。別事業者なら、別の検証経路が要る。どちらでも、ドメイン権利、制御チャネル証明書、DNSSEC 秘密鍵は異なる主体・期限・復旧手順を持ち得る。
移行計画は三者を明示的に結ぶ必要がある。誰が親を変更できるか。どの HNA 資格情報が DM を操作できるか。どの鍵が現行ゾーンを署名したか。旧事業者はいつ応答を止めるか。この対応表を一台のルーターだけに閉じ込めると、初期化や交換によって撤回権まで失う。
撤回ができて初めて委任は制御されている
RFC 9526 は HNA に、特定 DM の委任を削除する能力を要求する。DM は削除指示を受けたら Public Homenet Zone の提供を止め、完了を示す NOERROR を返せる。
だがその応答は DM の状態だけを示す。公開権威ノード、親 NS・DS、再帰キャッシュは別の時計で消える。移行中には新旧二つのサービスが同時に有効な署名を返す可能性もある。
撤回の証跡には、旧 DM、全公開エンドポイント、親レコード、TTL、署名の残存期間、新サービスの開始時刻を含めるべきだ。作成時の「存在」だけでなく、終了時の「不在」を観測してこそ、権限が残留していないと言える。
非稼働 HNA をいつ削除するかは商業契約が決める。利用者が要求する技術的撤回と、事業者が行う契約上の整理は別の権限であり、別の異議申立て経路を持つ。
番号変更は同時更新ではない
家庭のプレフィックスが変わると、HNA は新しい AAAA を作り、同期チャネルの新しい場所を DM に知らせ、新しい転送を起こす。make-before-break では旧新のアドレスが共存し、急な番号変更では旧アドレスが先に使えなくなる。
HNA は起動のたびに同期先情報を更新すべきだとされる。停止時間も署名ゾーンの失効も自分では確定できないからだ。望ましいアドレス、HNA のシリアル、DM の取得版、公開サーバーの提供版、親 DS、キャッシュは、同一トランザクションでは変わらない。
監視は「DNS は正常か」ではなく、各境界がどの世代を、いつまで正しいと見なしているかを比較する。古いアドレスが正しくキャッシュされながら到達不能になることも、新しい名前が公開されながらアクセス方針に阻まれることもある。
情報源
- RFC 9526 情報
- RFC 9526 HTML
- RFC 9526 テキスト
- RFC 9526 XML
- IETF Datatracker
- IETF Datatracker API
- RFC 9527:Homenet 命名の設定
- RFC 8499:DNS 用語
- RFC 2136:DNS UPDATE
- RFC 9103:TLS 上のゾーン転送
- RFC 8446:TLS 1.3
- RFC 4034:DNSSEC リソースレコード
- RFC 7344:委任信頼の自動保守
- RFC 8375:
home.arpa - RFC 7788:Home Networking Control Protocol
- Heng Lu:Reality Layers
- Heng Lu:Running-Code Primacy
- Heng Lu:Minimum Initial Specification
出典
- https://www.rfc-editor.org/info/rfc9526
- https://www.rfc-editor.org/rfc/rfc9526.html
- https://www.rfc-editor.org/rfc/rfc9526.txt
- https://www.rfc-editor.org/rfc/rfc9526.xml
- https://datatracker.ietf.org/doc/rfc9526/
- https://datatracker.ietf.org/api/v1/doc/document/rfc9526/
- https://www.rfc-editor.org/rfc/rfc9527.html
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://www.rfc-editor.org/rfc/rfc2136.html
- https://www.rfc-editor.org/rfc/rfc9103.html
- https://www.rfc-editor.org/rfc/rfc8446.html
- https://www.rfc-editor.org/rfc/rfc4034.html
- https://www.rfc-editor.org/rfc/rfc7344.html
- https://www.rfc-editor.org/rfc/rfc8375.html
- https://www.rfc-editor.org/rfc/rfc7788.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
