DNS over HTTPS(以下、DoH)は、DNS(名前解決)の問い合わせをHTTPS(HTTPをTLSで保護した通信)に載せて行う仕組みです。DNS問い合わせが暗号化されるため、ネットワーク上で第三者に盗み見られにくくなり、途中で内容をすり替えられにくくなります。
従来のDNSは、家庭や社内のネットワーク、公共Wi-Fiなどを通る途中で「どのドメイン名を引いたか」が見えやすいという弱点がありました。DoHはこの弱点を補い、DNS問い合わせの盗聴(見られる)と改ざん(すり替えられる)のリスクを下げることを主目的としています。
なお、DoHは「DNS問い合わせの経路を守る」技術です。通信の中身(Webページの内容やダウンロードしたファイル自体)を守るのはHTTPSなど別の仕組みなので、DoHだけで安全が完結するわけではありません。
HTTPSは、HTTP通信をTLSで暗号化し、盗聴や改ざんを防ぐ仕組みです。DoHは、このHTTPSの仕組みを使ってDNS問い合わせを行います。つまり、DNSの問い合わせがHTTPS通信の一部として扱われるのがDoHの特徴です。
ユーザーがWebページを開くとき、ブラウザやOSは「そのドメイン名がどのIPアドレスか」をDNSで問い合わせます。このときDoHが使われると、DNS問い合わせがHTTPSで保護された通信として送受信されます。
この結果、ネットワーク上でDNS問い合わせをのぞき見されるリスクが下がります。また、同じ経路上でDNS応答を差し替えるような攻撃も起こしにくくなります。
従来のDNS問い合わせは、主にUDP/53(場合によってはTCP/53)で平文送信されることが多く、ネットワーク上で内容が見えやすいという問題がありました。これに対し、DoHはDNS問い合わせをHTTPSで暗号化するため、第三者が内容を読み取ることは難しくなります。
また、従来のDNSでは、ネットワーク上の攻撃者がDNS応答を偽装して、偽サイトへ誘導するリスクがありました。DoHは、DNS問い合わせ自体がTLSで保護されるため、途中経路での偽装・改ざんを起こしにくくします。
ただし、DoHは「DNSの宛先(DoHリゾルバ)が正しいこと」「そのリゾルバが返す回答が信頼できること」まで自動的に保証する技術ではありません。信頼できるDoHリゾルバを使うこと、必要に応じてDNSSECなど他の仕組みも含めて設計することが大切です。
近年、公共Wi-Fiや外出先ネットワークの利用が増え、通信経路上での盗聴・改ざんリスクが問題になってきました。DNSはWeb閲覧やアプリ通信の入口にあるため、DNSが見られると「どのサイトを見たか」に近い情報が推測されやすく、プライバシーの観点でも課題があります。
こうした背景から、DNS問い合わせも暗号化して保護しようという流れが強まりました。その選択肢のひとつがDoHであり、DNS問い合わせのプライバシーと安全性を高める手段として注目されています。
DoH(DNS over HTTPS)は、その名の通りDNS問い合わせをHTTPSプロトコルで送る方式です。TLSによりDNS問い合わせが暗号化されるため、外部からの盗聴や改ざんを受けにくくなります。
また、HTTP/2やHTTP/3(QUIC)などの仕組みと相性がよく、同じ接続を使い回せるため、環境によっては通信効率が良くなる場合もあります。
利用方法は端末やブラウザによって異なります。ブラウザ側でDoHを有効化できることもあれば、OS側の設定や、企業ネットワークのポリシーに従う必要がある場合もあります。「何もしなくても常に有効」という言い方はできないため、利用状況は設定画面や運用ルールで確認するのが確実です。
DoHの大きな利点は、DNS問い合わせが暗号化されることで、通信経路上から閲覧先ドメインの情報が見えにくくなる点です。従来のDNSでは、同じネットワークにいる第三者や、経路上の機器がDNS問い合わせを観測できる可能性がありました。
DoHを使うと、少なくとも「ネットワーク上でDNS問い合わせが丸見えになる」状態は避けやすくなります。その結果、利用者の行動が追跡されにくくなり、プライバシー保護の面でメリットが出ます。
一方で、DNS問い合わせが暗号化されるということは、DoHリゾルバ(問い合わせ先)側に問い合わせが集まりやすいという面もあります。プライバシーをどう扱うリゾルバか(ログ方針、運用主体、規約など)も含めて選ぶ必要があります。
DoHは、DNS問い合わせの途中経路での盗聴や改ざんを難しくするため、一定のセキュリティ向上が見込めます。特に、公共Wi-Fiなど、ネットワーク自体を信用しにくい環境では効果が分かりやすいでしょう。
DNS応答を偽装して別サイトへ誘導する攻撃(例:DNS応答のすり替え、DNSキャッシュポイズニングなど)は、攻撃の成立条件がいろいろありますが、DoHは「経路上ですり替える」タイプの攻撃を起こしにくくします。
ただし、DoHは万能ではありません。DoHリゾルバ自体が悪意ある運用だったり、端末がマルウェアに感染していたりすると、別の経路で危険が残ります。DoHはあくまで「DNS問い合わせの経路保護」であり、端末防御やWebの安全対策と組み合わせて考える必要があります。
DoHによりDNS問い合わせと応答はTLSで保護されます。これは「途中の第三者が内容を読み取ったり、すり替えたりしにくい」状態を作るという意味で、改ざん耐性を高めます。
ただし、「DNSの答えが正しいこと」を最終的に保証する仕組みは、DoHそのものではありません。DoHは輸送路(トランスポート)を守る技術であり、回答の正当性を検証する仕組みとしてはDNSSECなど別の考え方があります。目的に応じて、DoHだけで足りるのか、DNSSECなども必要かを整理すると誤解が減ります。
DoHと似た技術にDoT(DNS over TLS)があります。どちらもDNS問い合わせを暗号化する点は同じですが、違いは「運ぶ方法」です。
運用のしやすさや監視・制御の設計は環境によって変わります。個人利用ではDoHが手軽な場面もありますが、企業・学校などでは、内部DNSや監査要件との整合でDoTや別方式を選ぶこともあります。
DoHはDNSの盗聴・改ざんリスクを下げる一方で、運用面では悩ましい点もあります。「安全になるから常に正解」というより、環境に合うかを見て判断することが大切です。
DoHを使うと、DNS問い合わせがHTTPS通信として扱われるため、ネットワーク側がDNS内容を見て行っていた制御(不適切サイトのブロック、内部ドメインの解決、監査など)が難しくなる場合があります。
例えば、家庭や学校でDNSフィルタリングにより有害サイトを制限しているとき、端末が外部のDoHリゾルバに直接問い合わせると、ネットワーク側の制御を迂回する形になることがあります。保護者・管理者の意図した制御が効かなくなる可能性があるため、方針を決めて設定を合わせる必要があります。
広告ブロック自体はブラウザ拡張のフィルタで実現されることも多いですが、ネットワーク側やローカルDNSで広告ドメインを引けないようにする方式(DNSベースのブロック)を使っている場合、DoHが外部リゾルバへ迂回すると、想定通りに動かなくなることがあります。
「DoHで広告ブロッカーが必ず無効化される」とまでは言えませんが、DNSベースの制御をしている環境では影響が出る可能性があります。
DoHはHTTPS通信を使うため、環境によってはDNSが遅くなることがあります。特に、DoHリゾルバが遠い、回線が混雑している、端末の電波状況が悪い、といった条件が重なると体感に出ることがあります。
一方で、HTTP/2/3の接続再利用や、リゾルバの性能次第では、むしろ安定・高速になる場合もあります。体感が悪いときは、DoHリゾルバの変更、企業・家庭のDNS設計の見直しなどを検討するとよいでしょう。
DoHはセキュリティを強化する有効な手段ですが、インターネット上のリスクをすべて排除するものではありません。DoHが守るのは主に「DNS問い合わせの経路」であり、端末がマルウェアに感染している場合や、危険なサイトを利用してしまう場合、別の経路で被害が起こり得ます。
また、DoHリゾルバが返す回答の信頼性(ログの扱い、ポリシー、ブロック方針など)も重要です。DoHは「どこに問い合わせるか」を変える面もあるため、運用主体を含めた設計が欠かせません。
DoHは「DNSをHTTPSに載せる」仕組みなので、Webで使われている通信技術を多く活用します。ここでは誤解が起きやすい点も含めて整理します。
DoHはDNS問い合わせをHTTPSで送ります。HTTPSはTLSにより暗号化され、盗聴や改ざんを防ぎます。従来のDNSは平文で観測されやすかったのに対し、DoHではDNS問い合わせも暗号化されるため、途中の第三者が内容を見たり差し替えたりしにくくなります。
DoHはHTTPS通信の一種なので、通常はサーバ側がデジタル証明書を提示し、端末(クライアント)がそれを検証することで「接続先が正しいサーバか」を確認します。これにより、途中で別サーバに誘導されるリスクを下げられます。
ただし、この認証は「接続先のサーバが、そのドメインの正当なサーバであること」を確認する仕組みであり、「DNSの回答内容が常に正しい」ことまで保証する仕組みではありません。ここを混同しないことが重要です。
DoHでは、DNSの問い合わせ・応答をHTTPSで運びます。結果として、DNS内容が暗号化され、盗聴が難しくなります。また、TLSにより途中改ざんが起きにくくなります。
一方で、すべての通信が暗号化されるわけではありません。DoHはDNSの経路保護であり、Webアクセスの本体はHTTPS、ファイルの安全性はマルウェア対策、端末の保護はEDRなど、役割分担があります。
企業や学校では、内部システム向けの名前解決(社内ドメイン、分割DNS、VPN利用時の名前解決など)や、監査・ログ・アクセス制御の要件があることが多いです。そのため、端末が外部のDoHリゾルバへ直接問い合わせると、運用が崩れる場合があります。
この場合は、
といった形で、全体設計の中でDoHを位置付けるのが現実的です。
DoHは「DNSも暗号化する」という流れの中で普及が進んできました。今後は、個人利用での手軽さだけでなく、企業・組織での運用に適合させる工夫がより重要になっていくと考えられます。
DNSの暗号化が一般化すると、盗聴・改ざんに対する基本耐性は上がります。一方で、運用側は「どこへ問い合わせるか」「ログや制御をどう扱うか」といった設計がより問われます。DoHを導入する際は、端末・ネットワーク・クラウドの役割分担を整理し、他のセキュリティ対策と矛盾しない形にしていくことが重要です。
DoHは、ゼロトラスト/SASE、SWG(セキュアWebゲートウェイ)、EDRなどの対策と組み合わせて考えることで、効果が分かりやすくなります。DNSを暗号化しつつ、必要な可視化や制御をどこで担保するか(端末側か、組織のリゾルバか、ゲートウェイか)を決めると、導入の失敗が減ります。
現在はブラウザ中心の利用が目立ちますが、OSやアプリ側がDNS暗号化を扱うケースも増えています。その結果、利用者が意識せずとも暗号化DNSが使われる場面は増えていく可能性があります。だからこそ、個人利用でも組織利用でも「いま自分のDNSがどこへ流れているか」を把握しておくことが大切です。
DoHを活かすコツは、目的をはっきりさせることです。公共Wi-Fiでの盗聴対策なのか、家庭内のプライバシー保護なのか、企業でのセキュリティ強化なのかで、最適な設定や運用は変わります。
「DoHをONにする」だけで終わらず、DoHリゾルバの選び方、端末やブラウザの設定、組織のポリシーや監視設計まで含めて検討すると、メリットを得ながらデメリットを抑えやすくなります。
DNS問い合わせを暗号化し、経路上で盗聴・改ざんされにくくする技術です。
なりません。DoHはDNSの保護であり、Webの中身や端末の安全は別の対策が必要です。
DNS問い合わせが暗号化される点です。従来DNSは平文で見えやすい場合があります。
どちらもDNSを暗号化しますが、DoHはHTTPSで運び、DoTはDNS専用のTLS接続で運びます。
途中経路でのすり替えは起きにくくしますが、回答の正当性まで自動的に保証する技術ではありません。
影響する場合があります。DNSフィルタリングを迂回してしまい、制限が効きにくくなることがあります。
必ず無効化するわけではありませんが、DNSベースのブロックは影響を受けることがあります。
あります。リゾルバまでの距離や回線状況で遅延が出る場合があり、逆に速くなる場合もあります。
内部DNSや監査・制御の設計と衝突することがあります。ポリシーで制御した設計が必要です。
運用主体、ログ方針、ポリシー、性能、組織要件との整合を基準に選びます。