要約

  • RFC 9726が明確にするのは、MUDに記載されたDNS名はそのままではパケット規則にならず、コントローラが特定の時刻・リゾルバ・キャッシュ・ネットワーク位置に依存するアドレス集合へ投影しなければならないという事実である。
  • 監査可能な制御には、MUDの版と真正性、機能名、機器とコントローラのリゾルバ、DNS応答とTTL、ACL生成・設置、パケット判定、接続先の身元、ファームウェア検証、実機結果を別々の証拠として保存する必要がある。

午前九時、MUDコントローラはメーカーの更新用ホスト名を解決し、二つのアドレスを許可する規則を生成した。配布先のファイアウォールはハッシュの一致を確認し、成功を返した。運用画面は緑色になった。

数分後、CDNは新しいアドレスを返した。機器側のキャッシュは更新済みだったが、コントローラ側の応答はまだTTL内にある。機器はメーカーが現在案内する宛先へ進み、ファイアウォールは昨日ではなく数分前の正しい規則でそれを拒否した。二つの時計の差が、規則の正しさを運用上の誤りへ変えた。

ここには悪意も破損も要らない。MUD文書、DNS、CDN、コントローラ、ファイアウォールがそれぞれ仕様どおりに動いても、同じ名前の実行可能な意味について一致しないことがある。RFC 9726が扱うのは、この変換を「設定済み」という一語で消さないための境界である。

永続する名前と一時的な規則

Manufacturer Usage Descriptionは、機器が必要とするネットワーク動作をメーカーが宣言する仕組みである。更新、遠隔測定、時刻同期を機能別のDNS名で表せば、将来の配信基盤をすべて事前に固定する必要がない。メーカー管理の別名をCDNへ向ければ、MUDファイルを配り直さずに裏側を移せる。

しかしパケット処理点に届くのは、通常、名前ではない。見えるのはIPアドレス、ポート、プロトコルであり、HTTPSのパスや「この機器が直前にどの名前を引いたか」はACLから消えている。そこでコントローラはDNSを問い合わせ、得られたアドレス集合を規則へコンパイルする。

生成されたACLはMUDの意味そのものではない。問い合わせ時刻、使用した再帰リゾルバ、キャッシュ状態、問い合わせ元の位置、CNAME連鎖、コンパイラ版を持つ派生物である。設置成功は、その派生物が特定の執行点に届いたことしか証明しない。機器が同じ答えを見ること、アドレスが当該サービス専用であること、そこから安全なコードが届くことは別の命題だ。

したがって、元のMUDバイト列と署名確認、使用された機能名、DNS応答全文とTTL、リゾルバID、生成規則、設置受領、パケット照合、TLS相手、アプリケーション処理、機器状態を分離して残すべきである。単一の「準拠」フラグに潰せば、原因を担当層へ戻せなくなる。

同じ名前に複数の正しい現在がある

古典的なDNSラウンドロビンでは、完全なアドレス集合の並び順だけが違う場合がある。機器とコントローラが同じ全集を得るなら、順序は許可範囲を変えない。現在の配信制御はもっと選択的だ。CDNは地理、回線、負荷、クライアントサブネットに応じて一部だけを返すことがある。

クラウド上のコントローラが東京から問い合わせ、家庭内の機器が大阪のISPリゾルバを使えば、両者の応答は異なり得る。どちらも権威DNSに認められた答えである。EDNS Client Subnetがトポロジ情報を加えれば、再帰サービスごとの採用、置換、解釈の差も生じる。

時間差も同じくらい重要だ。コントローラが九時に得た応答のTTLを正しく尊重している間に、権威側が九時四分に次の集合を出す。機器のキャッシュだけが更新されれば、「両者がDNSを守った」ことと「両者が同じアドレスを持つ」ことは両立しない。

RFC 9726は、機器とコントローラが同じ再帰リゾルバを使うことを推奨する。共通キャッシュは地理的な選択、部分集合、TTLを揃えやすい。家庭用ゲートウェイではリゾルバ、MUDコントローラ、ファイアウォールが同じ装置に入り、再起動時点まで共有できる。企業やクラウド管理では、機器のリゾルバを把握できず、同じネットワーク視点から問い合わせることも難しい。

運用上問うべきは「DNSが成功したか」ではなく、意思決定する部品が意図して同じ視界を持つか、違うならその差を観測して調停できるかである。

暗号化DNSで移動する観測権限

機器がネットワーク提供のリゾルバを避け、公衆の暗号化DNSへ直接問い合わせれば、ローカル区間の盗聴耐性は上がる。一方で外部事業者が問い合わせを見て、MUDコントローラは対応するACLを作るための手掛かりを失うかもしれない。

RFC 9726はIoT機器に対し、DHCPやRouter Advertisementで与えられたリゾルバを優先するよう勧める。IPv6のルータ広告はDNS設定を伝えられ、ネットワーク指定の暗号化リゾルバを発見する仕組みもある。ローカルの暗号化リゾルバなら、経路上の保護と共通の解決視界を同時に維持できる。

ただしローカルDNSは常に安全とは限らない。故障または悪意のあるサービスから機器を救うため、外部へのフォールバックが必要な場合はある。条件は明文化すべきだ。ローカルで完全な失敗が繰り返された後に限ること、定期的に復帰を試すこと、フォールバック先そのものがMUD規則で到達可能なことを確認する。プライバシー、一貫性、継続性の選択を、ライブラリの既定値へ隠してはならない。

Oblivious DoHは中継とターゲットを分離し、問い合わせ内容とクライアントアドレスが一主体へ集まるのを避けられる。しかし、それでも機器が次の接続に使った答えをコントローラへ自動的に伝えない。秘密を守る設計と、執行判断を説明する証拠は別物である。

名前の安定性には設計が要る

更新、遠隔測定、時刻取得を一つの包括的ホスト名に束ねると、個別機能を許可、停止、調査できない。メーカーが管理する機能別名は、運用上の権限を分けるための接点になる。その先にCDNがあっても構わないが、応答の変化速度がコントローラの更新能力を超えないことが必要だ。

極端に短いTTL、アプリケーション応答内で突然示される任意名、未開示事業者へのリダイレクト、予測不能なホスト選択は、精密に見える許可規則を偶然へ変える。逆に共有ホスティング全体を許せば安定するが、意味は失われる。ファイアウォールにはHTTPSパスが見えず、同じアドレス上の別テナントを区別できない。

IPアドレスをMUDへ直書きする案も、変換を消す代わりに変更リスクをファームウェア、MUD改訂、IPv4/IPv6、NAT64、証明書運用、緊急復旧へ移すだけだ。

未知の宛先をPTRで逆引きしても、失われた意図は戻らない。逆引きは存在しないことがあり、共有基盤の名前しか示さないことがあり、機器がどの正引き名を使ったかを証明しない。調査の補助にはなるが、後付けの承認根拠にはできない。正引きの瞬間に名前、応答、連鎖、所有する規則を記録する必要がある。

誤検知が制度を無効にする

不正確なMUDまたは古いDNS投影は、正当な通信を例外として報告する。最初の数件は丁寧に調査される。数十件になると一括例外が作られ、数百件になると通知が抑制される。最後に本物の逸脱が現れたとき、仕組みは動いていても人が信じない。

これは規則を曖昧にすべきだという話ではない。正しい層について精密であるべきだという話だ。異なるDNS視点から作った狭いアドレス集合は、精密さの外観しか持たない。RFC 9726が、実運用で壊れ続ける理想的ファイルより、多少広くても十分に正確なファイルを選ぶよう促す理由はここにある。

例外を見たら、許可を広げる前に原因を分類する。MUDが古いのか、リゾルバが違うのか、TTLと変更時刻がずれたのか、CDNが別名を導入したのか、機器が指定リゾルバを迂回したのか、最新規則の配布が遅れたのか、本当に未宣言先へ接続したのか。各原因はメーカー、DNS運用者、コントローラベンダー、現場ネットワーク、機器の別々の責任である。

到達可能性と安全な更新を分ける

MUD規則が更新サーバへの接続を許し、DNSが解決し、ファイアウォールが転送したとしても、安全な更新が完了したとは言えない。到達可能性の後には、接続先の身元、マニフェスト、署名またはハッシュ、対象機器への承認、インストール、起動、健康確認、ロールバックがある。

ファームウェア更新アーキテクチャは、それぞれの役割と受領を分けている。ネットワーク許可を安全証明に昇格させれば、コントローラが観測していない機器状態まで保証したことになる。逆に一度の拒否を攻撃とみなし、すべての新規アドレスを自動許可すれば、より大きな露出を生む。

有用な記録には少なくとも六つの時計がある。メーカーがMUDを発行した時刻、コントローラが取得・検証した時刻、DNS問い合わせ時刻、TTLの開始と終了、ACLの生成・有効化時刻、機器の名前解決と送信時刻である。更新処理にはさらにマニフェスト検証、インストール、再起動の時刻が続く。

この証拠なら、「九時五分、機器は指定リゾルバの新しい答えへ送信し、ファイアウォールは九時に別集合から作られた規則を実行していた」と限定的に述べられる。追加証拠なしに、侵害、CDN障害、機器乗っ取り、更新成功を主張することはできない。

Lu Hengの最小初期仕様の原則に従えば、MUDは移植可能な期待動作だけを標準化し、リゾルバ選択、例外処理、現場リスクまで中央へ奪う必要はない。現実の層を分ければ、署名済み文書、DNS応答、ACL、パケット判定、動作する機器が互いの権威を借りない。実装優先とは、整った文書より、現時点の解決履歴、規則ハッシュ、実機結果を重く見ることである。

RFC 9726はDNSの運用作法だけを語っていない。永続する名前を、期限付きの実行物へ変換する組織の責任を語っている。規則の受領が成功した瞬間こそ、その規則がどの現在を表しているかを問わなければならない。

出典