DNS フィルタリングは、悪性ドメインへのアクセスを止めたり、社内や家庭内の名前解決を統制したりするために有効な手段です。しかし、DNS クエリの監視や制限だけをセキュリティ境界として考えると、DoH によって簡単に迂回される可能性があります。
この記事では、DoH そのものを悪い技術として扱うのではなく、DNS 制御が効く範囲と、ブラウザやアプリケーション側の名前解決によって崩れる前提を分けて考えます。
この記事で扱う内容は次の通りです。
- DoH が DNS フィルタリングに与える影響
- DNS 53 番の監視だけでは見えない名前解決
- ブラウザ内蔵 DNS 設定と OS 側 DNS 設定の違い
- DNS、プロキシ、Firewall、端末管理の責務分離
- 業務環境や内部ネットワークでの現実的な設計
| 対象 | DNS フィルタリング、DoH、ブラウザ名前解決 |
|---|---|
| 主な論点 | DNS クエリ制御だけをセキュリティ境界にしない |
| 関係する層 | DNS、HTTPS、プロキシ、Firewall、端末管理、ブラウザポリシー |
書籍
DNS の基本、名前解決、権威 DNS、キャッシュ DNS、DNSSEC などを体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るDoH とは何か
DoH は DNS over HTTPS の略で、DNS クエリと DNS レスポンスを HTTPS の通信として送受信する方式です。従来の DNS は主に UDP 53 番を使いますが、DoH は HTTPS の上で DNS メッセージを扱います。
DoH は、DNS を暗号化し、信頼できないネットワーク上での盗聴や改ざんを減らすためには有効です。公衆 Wi-Fi や外部ネットワークでは、利用者のプライバシー保護という意味もあります。
| 方式 | 特徴 |
|---|---|
| 従来の DNS | 主に UDP 53 番を使う。ネットワーク機器から問い合わせ先や問い合わせ内容を観測しやすい。 |
| DoT | DNS over TLS。専用の TCP 853 番を使うため、通信種別は比較的識別しやすい。 |
| DoH | DNS over HTTPS。通常の Web 通信と同じ HTTPS 経路に乗りやすい。 |
DoH が問題になる理由
DoH 自体は悪い技術ではありません。問題は、組織や家庭内で DNS を使って制御している場合に、その制御をアプリケーション側の DoH が迂回できる点です。
たとえば、社内 DNS で特定ドメインをブロックしていても、ブラウザが外部の DoH サーバーを直接使えば、OS に設定された DNS サーバーを通らずに名前解決できます。この場合、ネットワーク側で DNS 53 番を監視していても、その問い合わせは見えません。
| 項目 | 内容 |
|---|---|
| DNS フィルタリング | 指定 DNS を通る問い合わせには有効。 |
| アプリケーション DoH | OS の DNS 設定とは別に、ブラウザやアプリが外部 DoH を使える場合がある。 |
| 制御の抜け道 | DNS 53 番だけを制限しても、HTTPS 経由の DoH は別経路で名前解決できる。 |
ブラウザ側名前解決の限界を見る
近年のブラウザは、OS の名前解決設定だけに従う単純な存在ではありません。Secure DNS、DoH、独自の host resolver、プロファイルごとの設定、管理ポリシーなどが絡みます。
そのため、ネットワーク管理者が「端末の DNS は社内 DNS に向いている」と考えていても、実際にはブラウザが別の名前解決経路を使っている可能性があります。これは、内部サイトのトラブルシュートでも問題になります。
Chrome と Firefox で内部サイトの挙動が分かれた例は、Chrome で IPv6 ULA 宛て HTTPS が開けない でも扱っています。あの記事では DNS だけでは説明できない事象でしたが、どちらにしてもブラウザがネットワーク設計の前提を変える点は共通しています。
見えないことと制御不能は同じではない
DoH の DNS クエリ内容は TLS で暗号化されるため、ネットワーク上で従来の DNS のように問い合わせ名を直接見ることはできません。ただし、だからといって DoH をまったく検知・制御できないわけではありません。
既知の DoH サーバーへの通信、接続先 IP、SNI、証明書、プロキシログ、EDR、ブラウザ管理ポリシーなどを組み合わせれば、一定の制御は可能です。ただし、それは DNS 53 番を見るだけの運用より複雑です。
| 制御点 | 見えるもの | 限界 |
|---|---|---|
| DNS サーバー | DNS 53 番を通る問い合わせ | DoH やアプリ内名前解決は見えない |
| Firewall | 宛先 IP、ポート、通信量 | HTTPS の中身までは見えない |
| Proxy / SWG | Web 通信の接続先、認証、ログ | 未管理端末や直通通信は別制御が必要 |
| MDM / EDR | 端末側の設定やプロセス | 管理対象外端末には効かない |
DNS 制御だけをセキュリティ境界にしない
この記事の中心は、DNS クエリ制御だけを過信しないことです。DNS フィルタリングは有効ですが、それ単体で「外部通信を統制できている」と考えるのは危険です。
暗号化された通信が増えた現在では、ネットワーク境界で通信内容を見る前提が弱くなっています。DNS、HTTP、TLS、SNI、プロキシ、端末管理、認証、アプリケーション制御を分けて考える必要があります。
業務環境での現実的な落としどころ
企業や組織では、プライバシーや暗号化を尊重しながらも、業務環境へのアクセスや情報漏えい対策として一定の統制が必要になります。その落としどころは、単に DNS をブロックすることではなく、管理対象端末、管理対象ブラウザ、管理対象プロキシを組み合わせることです。
- 管理対象端末では、ブラウザの DoH 設定をポリシーで固定する
- 社内指定の DNS リゾルバまたはセキュア Web ゲートウェイへ寄せる
- 未管理端末は業務環境へ直接接続させない
- DNS だけでなく、認証、端末状態、プロキシログで判断する
- 内部 DNS と外部 DNS の責務を分ける
内部 DNS の設計は、Ubuntu 22.04 BIND 内部 DNS のように、再帰問い合わせの許可範囲を明確にすることが重要です。
確認に使える観点
DoH の影響を疑う場合は、OS の DNS 設定、ブラウザ設定、実際の通信先を分けて確認します。
dig example.com
curl -I https://example.com/DNS 53 番の問い合わせが見えていないのに Web アクセスが成立している場合、DoH、プロキシ、アプリケーション内 DNS、キャッシュなどを疑います。
ブラウザ単位の挙動差を見る場合は、Chrome、Firefox、curl で結果を分けます。
curl -4 -I https://example.com/
curl -6 -I https://example.com/DNSSEC との違い
DoH と DNSSEC は目的が違います。DoH は、DNS メッセージを HTTPS 上で送ることで、通信経路上の盗聴や改ざんを防ぎやすくします。一方、DNSSEC は、DNS 応答そのものが正しい権威から来たものかを検証する仕組みです。
つまり、DoH は通信路の保護、DNSSEC は応答データの検証に関係します。どちらも DNS に関係しますが、解決する問題は同じではありません。
まとめ
DoH 時代には、DNS クエリ制御だけで通信を統制できているとは言い切れません。DNS フィルタリングは有効ですが、ブラウザやアプリケーションが DoH を使うと、OS に設定された DNS サーバーを通らない名前解決が成立する場合があります。
そのため、DNS、プロキシ、Firewall、端末管理、ブラウザポリシー、認証を分けて設計する必要があります。DNS を見ているから安全、DNS を止めたから制御できる、という考え方は弱くなっています。
重要なのは、DoH を単純に悪者にすることではありません。DNS 制御がどこまで効くのか、どこから先はブラウザや端末管理、プロキシ設計の領域なのかを分けることです。
