要約

  • DoHはクライアントとリゾルバー間の通信を守るが、利用環境に適したリゾルバーを決めるものではない。
  • 指定リゾルバーの発見はネットワーク側サービスを暗号化へ移行できるが、採用するかはクライアントの選択ポリシーに残る。
  • 名前空間、フィルタリング、フォールバック、ログの法的所在はリゾルバー選択とともに移る。
  • 指定、認証、選択、名前空間、データ取扱いを一枚のリゾルバー・ポリシー地図にまとめるべきだ。

仮定の場面を考える。同じオフィスネットワークに、管理対象のノートPCが二台接続する。一台目のOSは、ネットワークが提示したリゾルバーの暗号化エンドポイントを検出して検証し、社内サービスの名前を引き続き解決できる。二台目ではブラウザーが公開DoHサービスを選ぶ。TLS接続は成功しているのに社内名は解決できず、ネットワークのDNSフィルターも経路から外れる。暗号化の不具合ではない。リゾルバーを選んだ主体と、その選択に伴うポリシーが異なるのだ。

RFC 8484はDNSの問い合わせと応答をHTTPS交換に載せ、TLSで機密性と完全性を確保する。同時に、ローカルポリシーや分割DNSがある環境では、選ぶサーバーによって同じ名前への回答が変わり得ると示す。平文DNSを前提とした監視やフィルターはDoHを観察できない。通信保護は前進だが、どのコンポーネントが回答者を選ぶのかという統治上の判断が前面に出る。

RFC 9462のDDRは、既知の非暗号化リゾルバーから、同じ運用者または連携する運用者の暗号化サービスへ切り替える手順を定める。Verified Discoveryでは、有効な証明書チェーンに加え、提示元リゾルバーのIPアドレスを含むsubjectAltNameが必要になる。Opportunistic Discoveryでは、暗号化サービスと非暗号化サービスが同一IPアドレスを使う場合に利用でき、この方式はプライベートIPまたはローカルIPに限ることが推奨される。通信経路は暗号化されるが、証明書名によるリゾルバーの本人確認は行われない。二つの方式は保証の強さが異なり、いずれもクライアント側の選択方針を置き換えるものではない。

RFC 9463では、ネットワークがDHCPv4、DHCPv6、IPv6 Router Advertisementを使って暗号化リゾルバーの情報を提示できる。認証ドメイン名、アドレス、プロトコル情報、優先度が含まれる。ただし、その提示がすべての端末を拘束するわけではない。OSやアプリケーションは別の設定と比較し、採用するか拒否するかを決められる。責任はアクセス網、端末基盤、アプリ、リゾルバー運用者にまたがる。

データ統治も移動する。RFC 8932は収集の最小化、運用上可能な最短の保持、担当者アクセスの制限、慣行の透明性を勧める。リゾルバー変更は処理場所、保持期間、ログに適用される法域、インシデント時の証拠を同時に変え得る。

そこで、端末群とネットワーク状況ごとにリゾルバー・ポリシー地図を持つ。ポリシー責任者と決定時刻、提示元、身元確認の方法、選択主体、対応する名前空間、適用する制御、フォールバックを記録する。さらに、問い合わせとログの管理者、保存期間、適用される法域を明記する。公開名と内部名の双方を試験し、ブラウザー、OS、DHCP、証明書、エンドポイントの変更時に再検証する。

情報源