要約

  • DET は 128 ビットの IPv6 形式の識別子であり、ロケータではない。RFC 9886 はこれを 2001:30::/28 配下の逆引き DNS ツリーに対応付ける。
  • 28 ビットの階層識別子は Registered Assigning Authority（RAA）と HHIT Domain Authority（HDA）に分かれる。DNS 委任は、名前解決だけでなく登録階層を示す公開証拠になる。
  • DET 名は HHIT レコードに解決しなければならず、UAS Remote ID の用途では BRID レコードも存在しなければならない。DNSSEC は頂点エンティティでは必須、その他のエンティティでは推奨である。

出発点は 3.0.0.1.0.0.2.ip6.arpa である。これは 2001:30::/28 の逆引き名前空間への入口で、そこから下位への委任が RAA、HDA などの管理階層を表す。ただし、名前解決が成功したという事実だけでは、対象が検証可能な登録資格を持つことにはならない。

HHIT RRType 67 は登録メタデータと正規の登録証明書を運ぶ。BRID RRType 68 は静的な UAS Broadcast RID 情報とエンドースメントを運ぶ。したがって、依存側は両者を同じものとして扱えない。HHIT は DET と登録資料・証明書を結び、BRID は UAS の放送リモートID用途に必要な静的情報を示す。UAS の場合、片方の存在で他方の要件を代用することはできない。

DNS 検証フィクスチャ

次のコマンドは再現可能な検査の出発点であり、特定の本番サービス、事業者、稼働率を示す測定ではない。

dig +dnssec 3.0.0.1.0.0.2.ip6.arpa NS
dig +dnssec 3.0.0.1.0.0.2.ip6.arpa DS
dig +dnssec <受信したDETから正確に計算した逆引きowner name> HHIT
dig +dnssec <同じowner name> BRID

運用者はまず委任、DS、RRSIG、検証経路を確認し、その後に HHIT の登録証明書を検査する。UAS Remote ID なら BRID の存在と内容も RFC に従って確認する。山括弧部分は実際の放送から計算する正確な名前を入れるという手順上の指示であり、有効な実例を主張する名前ではない。本稿は、正誤表 8822 と 8823 で修正された RFC 付録の例示バイト列を再掲しない。

RFC 9886 は、公開 DNS のデータとポインターを私的レジストリから分離する。公開 DNS は公開検証材料を提供し、私的レジストリは非公開データを保持し得る。しかし、個人識別情報を保護する AAA の方式は RFC の規定外である。現在の本番展開、普及、DIME やレジストリの可用性・遅延、ベンダーやリゾルバーの対応範囲、濫用、事故、プライバシー、追跡可能性の実績も、この事実パケットからは分からない。

頂点エンティティで DNSSEC が使われれば、検証者は認証済み DNS データを利用できる。DNSSEC がない場合、RFC 9886 は、連続する HHIT 参照によって証明書階層をたどり、登録を証明することをクライアントに求める。DNS 応答が返ることだけで、認証済みと扱ってはならない。証明書チェーンがつながることと、必要なレコード型が存在して内容が適切であることは別々に確認する。

公開鍵は署名検証のために公開資料へ現れる。RFC 9886 は、実行可能な場合、必要になるまで DET 配下のレコード型の公開を遅らせるよう推奨する。ただし、just-in-time の仕組み自体は RFC の対象外である。これは公開禁止や、プライバシー効果を測定した結論ではない。

出典