DoHは、DNSの問い合わせをHTTPSで送る方式です。先に要点を言うと、DNSのやり取りを暗号化し、通信の途中で見られたり書き換えられたりしにくくするために使います。
従来のDNSは、家庭や社内のネットワーク、公共Wi-Fiなどを通るときに、「どのドメイン名を引いたか」が見えやすい弱点がありました。DoHはこの弱点を補い、DNSのやり取りに対する盗聴と書き換えの危険を下げます。
ただし、DoHが守るのはDNSのやり取りが通る途中です。Webページの中身や受信したファイルそのものを守るのはHTTPSなど別のしくみなので、DoHだけで安全がそろうわけではありません。
HTTPSは、HTTPの通信をTLSで暗号化し、盗み見や書き換えを防ぐしくみです。DoHはこのHTTPSを使ってDNSの問い合わせを送ります。つまり、DNSのやり取りをWebの通信と同じ形で包んで送るのがDoHです。
Webページを開くとき、ブラウザやOSは、そのドメイン名に対応するIPアドレスをDNSで調べます。DoHを使うと、この問い合わせがHTTPSで守られた通信として送受信されます。
そのため、ネットワーク上でDNSの問い合わせをのぞき見される危険は下がります。経路の途中で応答を差し替えるような攻撃も起こしにくくなります。
従来のDNSは、主にUDP/53やTCP/53で平文のまま送られることが多く、ネットワーク上で内容が見えやすいのが弱点でした。これに対し、DoHはDNSの問い合わせをHTTPSで包んで送るため、第三者が内容を読み取りにくくなります。
また、従来のDNSでは、ネットワーク上の攻撃者がDNS応答を偽装し、別のサイトへ誘導する危険がありました。DoHはDNSのやり取りを保護するため、通信の途中で行う偽装や書き換えを起こしにくくします。
ただし、DoHだけで「返ってきた答えが常に正しい」とまでは言えません。使うDoHリゾルバが信頼できるかを見たうえで、必要ならDNSSECなど別のしくみも組み合わせて考える必要があります。
近年は、公共Wi-Fiや外出先のネットワークを使う場面が増え、通信の途中での盗聴や書き換えが課題になっています。DNSはWeb閲覧やアプリ通信の入口に当たるため、ここが見えると「どのサイトを見たか」に近い情報を読まれやすくなります。
そのため、DNSの問い合わせも暗号化して守ろうという流れが強まりました。DoHは、そのための選択肢のひとつとして広く使われるようになっています。
DoHは、DNSの問い合わせをHTTPSで送る方式です。DNSのやり取りが暗号化されるため、外から盗み見されたり書き換えられたりしにくくなります。
また、HTTP/2やHTTP/3(QUIC)と組み合わせると、接続を再利用できる場面があります。条件が合えば、応答の安定や速さにプラスに働くこともあります。
使い方は端末やブラウザで異なります。ブラウザ側でDoHを有効にできることもあれば、OSの設定や企業ネットワークの方針に従う場合もあります。何もしなくても必ず有効とは限らないため、設定の画面や運用ルールで確認するのが確実です。
DoHの大きな利点は、DNSの問い合わせが暗号化されることで、通信の途中から閲覧先のドメイン名を見られにくくなる点です。従来のDNSでは、同じネットワークにいる第三者や、経路の途中にある機器が問い合わせを観測できる場合がありました。
DoHを使うと、少なくとも「DNSの問い合わせがネットワーク上で丸見えになる」状態は避けやすくなります。そのぶん、利用者の行動を追いにくくする効果が見込めます。
一方で、問い合わせはDoHリゾルバに集まります。どの事業者に送るのか、ログをどう扱うのかといった点は、使う前に見ておく必要があります。
DoHは、DNSの問い合わせが通る途中での盗聴や書き換えを起こしにくくします。特に、公共Wi-Fiのようにネットワークそのものを強く信頼しにくい場面では、効果をイメージしやすいでしょう。
DNS応答を偽装して別のサイトへ誘導する攻撃にはいくつか種類がありますが、DoHは少なくとも通信の途中で行う差し替えを難しくします。
ただし、DoHは万能ではありません。DoHリゾルバ自体に問題があったり、端末がマルウェアに感染していたりすれば、別の経路で危険は残ります。DoHはDNSの経路を守る手段として位置づけ、端末側の防御やWeb側の対策と分けて考える必要があります。
DoHでは、DNSのやり取りをHTTPSで運びます。一般的な利用ではTLSが使われ、HTTP/3ではQUICの暗号化が使われます。どちらの場合も、途中の第三者が内容を読んだり差し替えたりしにくくなります。
ただし、「返ってきた答えが正しい」と最終的に確かめる役目までDoHが担うわけではありません。DoHは運ぶ途中を守るしくみであり、答えの正しさを確かめるにはDNSSECなど別の方法も考える必要があります。
DoHとよく似た技術にDoT(DNS over TLS)があります。どちらもDNSの問い合わせを暗号化する点は同じですが、違いは運び方です。
どちらが扱いやすいかは環境で変わります。個人で使う場合はDoHが手軽な場面もありますが、企業や学校では、内部DNSや監査で求める条件との整合からDoTや別の方式を選ぶこともあります。
DoHはDNSの盗聴や書き換えの危険を下げる一方で、運用では悩ましい点もあります。安全になるから常に正解と見るのではなく、自分の環境に合うかで判断することが大切です。
DoHを使うと、DNSの問い合わせがHTTPSの通信として扱われます。そのため、ネットワーク側がDNSの内容を見て行っていた制御、たとえば不適切なサイトの遮断、内部ドメインの名前引き、監査などが難しくなる場合があります。
たとえば、家庭や学校でDNSフィルタリングを使って有害なサイトを制限しているとき、端末が外部のDoHリゾルバへ直接問い合わせると、その制御を回り道する形になることがあります。管理する側が意図した制限が効きにくくなるため、方針に合わせて設定をそろえる必要があります。
広告の遮断はブラウザ拡張で行う場合もありますが、ネットワーク側やローカルDNSで広告用のドメインを引けないようにしている環境では、DoHが外部リゾルバへ流れることで、想定した動きにならないことがあります。
DoHで広告ブロッカーが必ず無効になるわけではありません。ただ、DNSベースの制御を使っている環境では影響が出ることがあります。
DoHはHTTPSの通信を使うため、環境によってはDNSが遅くなることがあります。特に、DoHリゾルバが遠い、回線の状態が悪い、端末の電波が不安定だと、体感に差が出ることがあります。
一方で、HTTP/2やHTTP/3で接続を再利用できたり、リゾルバの性能が高かったりすると、逆に安定して速く感じることもあります。遅さが気になるときは、DoHリゾルバの見直しや、家庭・企業のDNSの組み方を確認するとよいでしょう。
DoHは有効な手段ですが、インターネット上の危険をすべてなくすものではありません。守る対象は主にDNSが通る途中であり、端末がマルウェアに感染している場合や、危険なサイト自体を使ってしまう場合は、別の経路で被害が起こりえます。
また、DoHリゾルバが返す答えをどこまで信頼できるかも大事です。ログの扱い、運営元、独自のブロック方針などは、導入前に確認しておく必要があります。
DoHは、DNSをHTTPSに載せて送るしくみです。ここでは、誤解しやすい点を中心に整理します。
DoHはDNSの問い合わせをHTTPSで送ります。HTTPSはTLSによって守られるため、従来の平文DNSより、途中で見られたり書き換えられたりしにくくなります。
DoHはHTTPS通信の一種なので、通常はサーバー側がデジタル証明書を示し、端末側がそれを確かめます。これにより、別のサーバーへ誘導される危険を下げられます。
ただし、ここで確かめているのは「そのドメインに対応する正しいサーバーか」という点です。DNSの答えそのものが常に正しいかどうかまで、この確認だけで決まるわけではありません。
DoHでは、DNSの問い合わせと応答をHTTPSで運びます。その結果、DNSの中身は暗号化され、盗聴が難しくなります。一般的なHTTPSではTLSが使われ、HTTP/3ではQUICの暗号化が使われます。
一方で、すべての通信が一括で守られるわけではありません。DoHが担うのはDNSの経路で、Webアクセスの本体はHTTPS、ファイルの安全はマルウェア対策、端末の保護はEDRなどが担います。
企業や学校では、社内ドメイン、分割DNS、VPN利用時の名前引き、監査、ログ、アクセス制御など、DNSまわりに多くの条件があります。端末が外部のDoHリゾルバへ直接問い合わせると、今の運用が崩れることがあります。
そのため、
といった形で、全体の設計の中にDoHを置くのが現実的です。
DoHを入れる価値は、何を守りたいかで変わります。公共Wi-FiでDNSを見られたくないのか、家庭内で閲覧先の見えやすさを下げたいのか、企業で組織が管理する暗号化DNSを使いたいのかで、見る点は変わります。
個人で使うなら、使うリゾルバの運営元、ログ方針、端末やブラウザでの設定の手順、体感の速さを先に確認するとよいでしょう。DoHで経路上の盗み見は起こりにくくなりますが、どの事業者に問い合わせが集まるかは別の論点です。
企業や学校では、内部DNS、監査、アクセス制御、VPN、SWGやSASEとの関係を先に確認する必要があります。端末が外部のDoHリゾルバへ直接問い合わせる構成だと、今あるルールや名前引きのしくみとぶつかることがあります。
DoHだけで安全がそろうわけではありません。Web通信の保護はHTTPS、端末の保護はEDRなどが担うため、どこでDNSを暗号化し、どこで監視や制御を行うかを分けて考えることが大切です。
結局は、「どのDoHリゾルバを使うか」と「その設定が自分や組織の運用に合うか」を確かめることが大事です。機能をONにするだけで終わらせず、設定先、ログの扱い、既存のネットワークとの関係まで見て決めると、導入後のずれを減らしやすくなります。
DNSのやり取りが通る途中を守り、盗み見や書き換えを起こしにくくする技術です。
なりません。DoHが守るのはDNSが通る途中で、Webの中身や端末の安全は別の対策が要ります。
DNSの問い合わせをHTTPSで送る点です。そのため、平文DNSより内容を見られにくくなります。
どちらもDNSを暗号化しますが、DoHはHTTPSで運び、DoTはDNS専用のTLS接続で運びます。
通信の途中で行う差し替えは起こしにくくしますが、返る答えの正しさまでDoHだけで決まるわけではありません。
影響することがあります。DNSフィルタリングを使う環境では、意図した制限が効きにくくなる場合があります。
必ず無効にするわけではありませんが、DNSベースの遮断は影響を受けることがあります。
あります。リゾルバまでの距離や回線の状態で遅く感じる場合があり、逆に安定して速くなる場合もあります。
内部DNSや監査、アクセス制御のしくみとぶつかることがあります。方針に沿った設計が必要です。
運営元、ログ方針、性能、自分や組織の運用に合うかを見て選びます。