要約

  • RFC 9886 は DRIP Entity Tag を逆引き DNS に配置し、登録資料と静的な Remote ID 情報のために HHIT と BRID を定義する。
  • DET はロケーターではなく識別子であり、正しい応答だけでは機体の現在位置、運航、秘密鍵所持、メッセージ到達を証明できない。
  • 運用判断では、権威 DNS、DNSSEC、証明書、空中での所持証明、独立センサーの相関を別々の証拠として残す必要がある。

監視担当者が受け取ったのは、欠損のないデジタル身上書だった。128 ビットの DET、HHIT の公開鍵、正規の登録証明書、BRID の静的データ。チェーン検証にも成功している。これほど情報がそろえば、対象を地図に載せたくなる。

しかし、身上書は目撃情報ではない。

RFC 9886 は Drone Remote Identification Protocol のための公開照会面を定める。DET は IPv6 アドレスのように見えるが、主目的は識別であって位置指定ではない。128 ビットの形から、経路到達性や地理情報は生まれない。登録された暗号学的アイデンティティを指せても、それを担う機体が今どこにあり、飛行中か、誰の制御下にあるかまでは語らない。

逆引きゾーンと空域は別物

2001:30::/28 の DET は、3.0.0.1.0.0.2.ip6.arpa. 配下の逆引きツリーに置かれる。DNS の委任、キャッシュ、認証を利用できる点は大きい。ただし問い合わせるのは PTR ではなく、DRIP 固有の HHIT または BRID である。名前が引けたからといって、ルーティング可能な端点や物理地点が得られるわけではない。

制度上は、登録者、レジストラ、レジストリという役割が並ぶ。委任された領域ごとに権威サーバーが公開情報を提供し、上位では国の当局や民間航空当局との割り当てが想定される。IANA は対応する逆引き空間を管理する。RFC が共通化するのは技術的な登録・検索構造であり、各階層の管理方針や権限の全てではない。

権威応答の意味は、だから限定される。ある時刻に、ある権威サーバーが、あるバイト列を返した。その事実は強くできる。だが、サーバーが直接観測していない機体の物理状態まで同じ権威で断定することはできない。

HHIT と BRID の守備範囲

IANA の DNS Parameters では、タイプ 67 が HHIT、68 が BRID である。DET は HHIT に解決されなければならない。HHIT に含まれる正規登録証明書と公開鍵を使えば、DET が登録階層にどう位置づくかを検証できる。UAS Remote ID では BRID も必要で、静的な Broadcast Remote ID 情報やエンドースメントを保持する。アプリケーション固有フィールドの意味は DRIP 層の外にある。

これは有用な基盤だ。未知の Host Identity を受信した観測者は、鍵と登録資料を問い合わせられる。接続できない場合は、RFC 9575 に従ってメッセージを保存し、後で検証できる。受信できなかったブロードキャストを静的 BRID で補ったり、受信内容と照合したりもできる。

ただし、補完は現場観測の代用ではない。静的レコードは今この瞬間の電波ではない。公開鍵は現在の送信者が秘密鍵を持つ証明ではない。登録証明書は飛行許可でも耐空性の証明でもない。BRID の値はレーダー反射、GNSS 測位、光学追尾、コマンド応答のいずれでもない。

RFC 9575 は信頼チェーンの終点を明確にする。全リンクの検証に成功して分かるのは、DET と公開鍵が適切に登録されていることまでだ。観測中の無人航空機が対応する秘密鍵を持つかどうかは、ライブのプロトコル交換で所持証明を得なければならない。その前なら、過去の正しいメッセージのリプレイで既知の身份を装える。

DNSSEC が保証する一つの層

DNSSEC は、構成された信頼鎖における応答の出所と完全性を保証する。RFC 9886 は自己署名された頂点でこれを求め、階層全体での利用を推奨する。検証がなければ、偽データによるなりすまし、クローン、登録の乗っ取り、メタデータ改ざんが起こり得る。DNSSEC に頼れないクライアントは登録証明書チェーンを自ら検証する必要がある。

それでも DNSSEC は空を署名しない。登録内容が現在の物理状態と一致すること、機体が主張座標にいること、運航権限があること、命令を受け取ったことは別の問題だ。暗号学的な強さは、その主張の範囲内でのみ効く。範囲そのものを広げない。

これは「記録は現実を記述するが、現実を創造しない」という原則の実例である。薄い協調層には、唯一性、正確な参照、制御の証拠、セキュリティ表明、監査可能性を守る価値がある。共通台帳を万能な判定者にした瞬間、その価値は過剰な権力に変わる。

公開タイミングも証拠ではない

RFC 9886 は実用的な場合、公開鍵を必要な時にだけ公開することを推奨する。飛行前に有効化し、終了後に削除する運用も考えられる。長期露出を減らす一方で、「レコードがあるから飛行中だ」という別の誤推論を誘う。

実際には、取り消された計画のレコードが残ることも、実飛行中に接続障害で公開できないこともある。キャッシュは運航窓を越えて値を返し、TTL、ネガティブキャッシュ、時計差、リゾルバー経路が観測結果を変える。レコード公開と機体存在は、別々の時系列として照合すべきだ。

登録手続きには制度的な費用もある。資格情報、レジストラ契約、支払い、飛行前トランザクションは摩擦を増す。RFC 自身、動的登録が規模に耐えない可能性や代替割り当てを述べる。登録が活動の入口になれば、入口の管理者は唯一性維持を超える力を持ち得る。その力は明示的な根拠と異議申立てを必要とし、DNS 成功の裏に隠してはならない。

出典