DoHが暗号化する区間

DNS over HTTPS（DoH）はDNSの問い合わせと応答をHTTPSのHTTP交換として送ります。TLSは端末と設定済みDoHリゾルバーの間を暗号化し、接続先サーバーを認証します。その経路上の装置に見えるのは、平文DNSではなくHTTPS接続と通信メタデータです。ただし保護は選択したリゾルバーまでです。リゾルバーは問い合わせを処理するためドメイン名を見られ、接続情報と関連付けて保存・利用するかはサービスの運用・プライバシーポリシーによります。

DoHだけでDNS応答の正しさが証明されるわけではありません。HTTPSはクライアントとリゾルバー間の通信路を守り、DNSSECは署名されたDNSデータを検証します。守る対象が異なるため、一方が他方を自動的に置き換えるものではありません。

観察する場所ごとの違い

観察者通常見える情報DoHで変わる点
端末と選択したリゾルバーの間の経路端末・リゾルバーのIP、接続時刻、通信量TLSで問い合わせと応答の中身は守られますが、接続先やすべての通信分析の手掛かりが消えるわけではありません。
選択したDoHリゾルバー処理する問い合わせ・応答と接続メタデータリゾルバーを新たな信頼境界として選びます。保存期間や利用目的を確認します。
名前解決後に接続するWebサイトそのサイトへの接続と送信したリクエストDoHは後続のWeb通信を隠したり、接続先による利用者の識別を防いだりしません。

RFC 8484は、HTTPSの既定ポート443や他のHTTPS通信との接続共有が経路上の干渉を抑え、DNS通信の分析を難しくし得ると説明しています。すべてのネットワーク観察者にDoHが通常のHTTPSと区別できない、という意味ではありません。

HTTP要求形式とトランスポート

RFC 8484ではDNS wire-formatメッセージをHTTP GETまたはPOSTで送ります。GETではBase64URL形式のメッセージをURIのdns変数に入れ、POSTではバイナリメッセージを要求本文に含めます。メディアタイプはapplication/dns-messageです。HTTP/2はTCP上で動作し、HTTP/3はQUIC上でHTTPの意味を伝えます。DoHを単一の方式として「TCPとUDPの両方の443番ポートを使う」と説明しないでください。

仮想の導入例: 社内限定名がある企業

会社の端末がwiki.intra.exampleを社内DNSでのみ解決するとします。利用者がブラウザーだけを外部の公開DoHリゾルバーへ切り替えると、その問い合わせは社内の分割DNSやフィルターポリシーを経由しないことがあります。その結果、名前を解決できなかったり、監視・遮断が想定と異なったりする可能性があります。これは説明用の例であり、特定製品での実測ではありません。

導入前に次を確認します。

  1. どのリゾルバーを選び、問い合わせデータの保存・利用方針をどう確認するか。
  2. 社内限定ゾーン、分割DNS、脅威フィルター、障害時の代替経路が維持されるか。
  3. 管理端末でブラウザー固有の設定がシステムDNS方針と異なる経路を作らないか。
  4. 新規接続と再利用接続を分けて実際の遅延を測ったか。RFCだけでは個別環境の改善を判断できません。

現在の各社資料にはwire-format URIの例として、Cloudflare https://cloudflare-dns.com/dns-query、Google https://dns.google/dns-query、Quad9 https://dns.quad9.net/dns-queryが示されています。これは接続先形式の例であり、推奨やプライバシーポリシーの比較ではありません。設定前に各社の最新資料と組織の方針を確認してください。

参考資料