DoH で DNS フィルタリングは無効になるのか – Chrome、Firefox、Windows の制御点

DNS over HTTPS（DoH）が使われると、社内 DNS や DNS フィルタリングは無効になるのでしょうか。

結論から言えば、DNS フィルタリング自体が無意味になるわけではありません。ただし、フィルタリングが判断できるのは、その DNS リゾルバーを実際に通った名前解決だけです。Chrome や Firefox が組織の管理外にある DoH リゾルバーへ直接問い合わせれば、社内 DNS にはクエリが届かず、そこで設定した拒否、ログ、内部ドメインの応答は適用されません。

したがって、DoH 時代の設計では UDP / TCP 53 を監視するだけでは不十分です。どのアプリケーションが名前解決を行い、どのリゾルバーを選び、どのポリシーで固定し、迂回した通信をどの層で制御するのかを分けて考える必要があります。

DoH は DNS を HTTPS で運ぶ

DoH は、DNS メッセージを HTTPS で送受信する仕組みです。RFC 8484 で標準化されており、一般的な Web 通信と同じ TCP 443 上で使われます。

DoH が難しいのは、暗号化されることだけではありません。DNS 専用ポートではなく HTTPS を使うため、宛先 IP アドレスやポート番号だけでは、通常の Web アクセスと DoH を安定して区別できない場合があります。

DNS フィルタリングが効く範囲

DNS フィルタリングは、問い合わせを受けたリゾルバーが、ドメイン名に応じて応答を許可、拒否、置換する仕組みです。悪性ドメインを NXDOMAIN で返す、ブロックページ用アドレスへ向ける、カテゴリごとに応答を制御するといった処理は、管理対象の DNS リゾルバーにクエリが届くことを前提としています。

ここで問題になるのは、インターネット向けの有害ドメインだけではありません。社内専用ドメインや split DNS を使っている環境では、ブラウザが外部 DoH を選ぶと、内部名を解決できない、外部向けの異なるアドレスを受け取る、検索ドメインや NRPT の意図と異なる結果になる、といった不整合が起こります。

名前解決の主体を四つに分ける

「端末の DNS 設定を社内 DNS にしたから制御できる」とは限りません。名前解決の主体は、少なくとも次の四つに分けて確認します。

• アプリケーション：Chrome や Firefox が独自の DoH 機能を持ち、OS の設定とは別にリゾルバーを選ぶ
• OS：Windows などの DNS クライアントが DoH を使い、アプリケーションから受けた問い合わせを処理する
• ネットワーク：DHCP、VPN、固定設定などで社内 DNS のアドレスを配布し、UDP / TCP 53 や外部 DoH への到達性を制御する
• 出口サービス：Proxy、Secure Web Gateway（SWG）、SASE などが HTTP / HTTPS の宛先を認証、分類、記録する

この四つは代替関係ではありません。ブラウザポリシーで名前解決先を統制し、OS の設定を管理し、ネットワークで不要な経路を減らし、出口サービスで最終的な Web アクセスを評価する、という重ね方が必要です。

Chrome は DnsOverHttpsMode で制御する

Google Chrome では、企業向けポリシーの DnsOverHttpsMode で DoH の動作を管理できます。主な値は off、automatic、secure です。

組織が DoH を禁止する必要はありません。管理対象の DoH リゾルバーを DnsOverHttpsTemplates で指定し、暗号化されたまま社内のポリシーとログへ接続する設計もできます。重要なのは、利用者やブラウザの自動判断に委ねず、組織として選んだリゾルバーへ固定することです。

適用状態は Chrome のアドレスバーで chrome://policy を開き、DnsOverHttpsMode とテンプレート関連ポリシーを確認します。管理コンソール上の設定だけでなく、実際の端末へ反映されているかを見る必要があります。

Firefox は DNSOverHTTPS ポリシーで制御する

Mozilla Firefox には DNSOverHTTPS という企業向けポリシーがあります。DoH の有効化だけでなく、リゾルバー、利用者による変更、除外ドメイン、フォールバックを分けて設定できます。

内部ドメインだけを除外する設計では、サブドメイン、検索ドメイン、VPN 接続時の名前空間まで含めて対象を定義します。除外リストが漏れると、「一部の社内サイトだけ Firefox で開けない」という症状になります。適用状態は about:policies の Active で確認できます。

Windows の DoH はブラウザとは別に確認する

Windows の DNS クライアントも DoH を扱えます。これは Chrome や Firefox の独自 DoH とは別の制御点です。ブラウザが OS の名前解決を使う構成でも、Windows 側がどの DNS サーバーへ、暗号化あり・なしのどちらで問い合わせるかを確認する必要があります。

Windows Server 2022 のグループポリシーには、DoH を禁止、許可、必須にする設定があります。DoH を必須にする場合、設定した DNS サーバーが DoH に対応していなければ名前解決は失敗します。暗号化を有効にすることと、到達性やフォールバックをどう設計するかは別の判断です。

Windows が認識している DoH サーバー構成は、PowerShell で確認できます。

Get-DnsClientDohServerAddress

この結果は、ブラウザ独自の DoH リゾルバーを示すものではありません。Windows の設定、Chrome のポリシー、Firefox のポリシーを別々に確認し、最終的な問い合わせ先を対応づけます。

SNI や宛先 IP だけでは DoH を確実に判定できない

既知の DoH リゾルバーの FQDN、TLS の Server Name Indication（SNI）、宛先 IP アドレスを使えば、外部 DoH の一部を検知・遮断できます。ただし、これらは補助的な制御です。

• 同じ IP アドレスで通常の Web サービスと DoH が提供されることがある
• リゾルバーの FQDN や IP アドレスは追加・変更される
• 独自ドメインや自前サーバーで DoH を提供できる
• ECH が使われると、従来は平文だった SNI などの ClientHello 情報も暗号化される

RFC 9849 の Encrypted Client Hello（ECH）は、TLS の ClientHello を暗号化し、SNI や ALPN などを保護します。そのため、「TLS を復号しなくても SNI を見れば DoH の宛先が分かる」という前提は、常に成立するものではありません。

外部 DoH の IP アドレス一覧をファイアウォールへ登録する運用も、補助策にはなりますが、それだけを正とすると更新漏れと誤遮断を抱えます。管理端末では、ネットワーク上の推測より先に、ブラウザと OS のポリシーで名前解決先を固定する方が確実です。

DoH 時代の DNS 制御を層で設計する

すべての通信を一つの装置で完全に識別しようとすると、暗号化方式やブラウザ実装の変化に追随できません。名前解決先はエンドポイントで固定し、DNS は問い合わせを評価し、Web アクセスは Proxy / SWG で再評価し、逸脱は端末テレメトリーで検出する、という責任分担が現実的です。

障害切り分けでは結果と経路を分ける

名前解決の障害では、「名前が引けるか」だけでなく、「誰が、どのリゾルバーへ問い合わせた結果か」を確認します。

dig、nslookup、Resolve-DnsName の結果が正常でも、ブラウザが同じ経路を使っているとは限りません。CLI とブラウザで結果が異なる場合は、まず名前解決の主体が違う可能性を疑います。

DNSSEC と DoH は役割が違う

DNSSEC と DoH は、どちらも DNS の安全性に関係しますが、解決する問題が異なります。DNSSEC は DNS データの真正性を署名で検証する仕組みです。DoH はクライアントと DoH リゾルバーの間の通信を HTTPS で暗号化します。

DoH を使っても、信頼できないリゾルバーを選べば、そのリゾルバーがどのような応答やログ管理を行うかという問題は残ります。DNSSEC を使っても、クライアントとリゾルバー間のクエリ内容が自動的に秘匿されるわけではありません。暗号化、応答の真正性、フィルタリング、監査は別々に設計します。

参考情報

参考書籍

まとめ

DoH が使われても、DNS フィルタリングが無意味になるわけではありません。管理対象の DoH リゾルバーへ問い合わせを集約できれば、通信を暗号化しながら、内部 DNS、フィルタリング、ログを維持できます。

問題は、DNS の方式よりも、名前解決先を誰が決めているかです。Chrome、Firefox、Windows、社内 DNS、Firewall、Proxy / SWG の制御点を混同すると、設定上は社内 DNS を指定しているのに、実際のクエリは外部 DoH へ流れる状態が生まれます。

DoH 時代の DNS 制御では、エンドポイントでリゾルバーを固定し、社内 DNS で問い合わせを評価し、出口サービスで Web アクセスを再評価し、ログを相互に照合できる構造が必要です。DNS クエリを一つの装置で見ることではなく、名前解決から通信までの責任を層ごとに接続することが設計の中心になります。

関連記事

DNS 設計・運用メモ – DNSSEC、DoH、名前解決の限界を整理する .local ドメインを社内 DNS で使うべきではない理由 – mDNS と名前解決の衝突 DNSSEC で名前解決できない原因が NTP だった話