DoH 時代に DNS クエリ制御だけでは不十分な理由

DNS フィルタリングは、悪性ドメインへのアクセスを止めたり、社内の名前解決を統制したりするために有効な手段です。しかし、DNS クエリの監視や制限だけをセキュリティ境界として考えると、DoH によって簡単に迂回される可能性があります。

この記事は、以前書いた DoH への問題意識を、現在の前提に合わせて再整理したものです。DoH はすでに RFC 8484 として標準化され、ブラウザやアプリケーション、パブリック DNS サービスで広く使われる選択肢になっています。

DoH とは何か

DoH は DNS over HTTPS の略で、DNS クエリと DNS レスポンスを HTTPS の通信として送受信する方式です。従来の DNS は主に UDP 53 番を使いますが、DoH は HTTPS の上で DNS メッセージを扱います。

RFC 8484 では、DNS の問い合わせと応答を HTTP exchange に対応づけるプロトコルとして DoH が定義されています。つまり、DoH は単に DNS を暗号化するだけではなく、HTTP、TLS、キャッシュ、プロキシ、認証といった Web の仕組みの中に DNS を組み込む設計です。

項目	内容
従来の DNS	主に UDP 53 番を使う。ネットワーク機器から問い合わせ先や問い合わせ内容を観測しやすい。
DoT	DNS over TLS。専用の TCP 853 番を使うため、通信種別は比較的識別しやすい。
DoH	DNS over HTTPS。HTTPS 通信として扱われるため、通常の Web 通信と同じ経路に乗りやすい。

DoH が問題になる理由

DoH 自体は悪い技術ではありません。公衆 Wi-Fi や信頼できないネットワーク上で、DNS クエリの盗聴や改ざんを防ぐためには有効です。問題は、組織や家庭内で DNS を使って制御している場合に、その制御をアプリケーション側の DoH が迂回できる点です。

たとえば、社内 DNS で特定ドメインをブロックしていても、ブラウザが外部の DoH サーバーを直接使えば、OS に設定された DNS サーバーを通らずに名前解決できます。この場合、ネットワーク側で DNS 53 番を監視していても、その問い合わせは見えません。

項目	内容
DNS フィルタリング	社内 DNS や家庭内 DNS を通る問い合わせには有効。
アプリケーション DoH	OS の DNS 設定とは別に、ブラウザやアプリが外部 DoH を使える場合がある。
制御の抜け道	DNS 53 番だけを制限しても、HTTPS 経由の DoH は別経路で名前解決できる。

「見えない」と「制御不能」は同じではない

DoH の DNS クエリ内容は TLS で暗号化されるため、ネットワーク上で従来の DNS のように問い合わせ名を直接見ることはできません。ただし、だからといって DoH をまったく検知・制御できないわけではありません。

既知の DoH サーバーへの通信、接続先 IP、SNI、証明書、HTTP パターン、プロキシログ、EDR、ブラウザ管理ポリシーなどを組み合わせれば、一定の制御は可能です。ただし、それは DNS 53 番を見るだけの運用より複雑です。

項目	内容
DNS クエリ内容	TLS で暗号化されるため、ネットワーク機器から直接は見えにくい。
接続先	既知 DoH サーバーや DoH エンドポイントへの接続として検知できる場合がある。
端末側制御	ブラウザポリシー、MDM、EDR、プロキシ設定で DoH 利用を制御する。
ネットワーク側制御	許可するリゾルバを決め、外部 DoH への直接通信を制限する。

DNS 制御だけをセキュリティ境界にしない

この記事の中心は、DoH そのものの是非ではなく、DNS クエリ制御だけを過信しないことです。DNS フィルタリングは有効ですが、それ単体で「外部通信を統制できている」と考えるのは危険です。

暗号化された通信が増えた現在では、ネットワーク境界で通信内容を見る前提が弱くなっています。DNS、HTTP、TLS、SNI、プロキシ、端末管理、認証、アプリケーション制御を分けて考える必要があります。

項目	内容
DNS	名前解決の経路を制御する。DoH による迂回を考慮する。
Proxy / SWG	Web 通信の出口を集約し、ログとポリシーを適用する。
EDR / MDM	端末側でブラウザ設定や不審な通信を制御する。
Firewall	許可された宛先・ポート・経路に絞る。ただし HTTPS の中身までは見えない。
ID / 認証	ネットワーク位置ではなく、利用者と端末の状態でアクセスを判断する。

業務環境での現実的な落としどころ

企業や組織では、プライバシーや暗号化を尊重しながらも、業務環境へのアクセスや情報漏えい対策として一定の統制が必要になります。その落としどころは、単に DNS をブロックすることではなく、管理対象端末、管理対象ブラウザ、管理対象プロキシを組み合わせることだと思います。

たとえば、管理対象端末ではブラウザの DoH 設定をポリシーで固定し、社内指定のリゾルバやセキュア Web ゲートウェイを使わせる。未管理端末は業務環境へ直接接続させず、認証や端末状態で制限する。このように、DNS だけではなく端末と出口をセットで設計する必要があります。

なぜ HTTPS に載せるのか

以前の記事では、「なぜ DNS を HTTPS に含めてしまうのか」という疑問を書いていました。この疑問は今でも自然だと思います。DoT のように専用ポートを使えば、通信の種類は識別しやすくなります。

一方で、DoH は既存の HTTPS インフラを利用でき、ファイアウォールを越えやすく、Web アプリケーションとの親和性が高いという特徴があります。これは利用者のプライバシー保護には有利ですが、ネットワーク管理者から見ると統制が難しくなるというトレードオフがあります。

DNSSEC との違い

DNSSEC と DoH は目的が異なります。DNSSEC は DNS 応答の正当性を検証するための仕組みです。一方、DoH は DNS クエリとレスポンスを HTTPS で運ぶための仕組みです。

項目	内容
DNSSEC	DNS 応答が改ざんされていないか、権威ある情報かを検証する。
DoH	DNS 通信を HTTPS で暗号化し、経路上から問い合わせ内容を見えにくくする。
関係	目的は異なる。DoH を使っても DNSSEC の代わりにはならず、DNSSEC を使っても DNS クエリ自体は暗号化されない。

参考

RFC 8484 – DNS Queries over HTTPS

RFC 7858 – DNS over TLS

RFC 9230 – Oblivious DNS over HTTPS

まとめ

DoH は、DNS クエリを HTTPS に載せることで、利用者のプライバシーを高める技術です。一方で、DNS クエリに頼ったフィルタリングや監視は、DoH によって迂回される可能性があります。

重要なのは、DNS フィルタリングを否定することではありません。DNS フィルタリングは有効ですが、それだけをセキュリティ境界にしてはいけない、ということです。暗号化された通信が前提になった現在では、DNS、プロキシ、端末管理、認証、ログを組み合わせて、どこで統制するのかを設計する必要があります。