要点：古典的な DNS（1987年のプロトコル）は UDP port 53 を使ってクエリを平文で送信します。ネットワーク経路上の誰もが、あなたが調べているすべてのドメイン名を読み取り、応答を改ざんし、特定のクエリをブロックできます。DoT（RFC 7858、2016年）は port 853 上の TLS で DNS クエリをラップします。DoH（RFC 8484、2018年）は port 443 の HTTPS リクエスト内に DNS クエリを埋め込みます。どちらも平文の問題を解決します。両者が分かれるのは、デプロイを誰が管理するか、クエリを誰が見られるか、そして誰がブロックできるか、という点です。「どちらを使うべきか」と問われるとき、多くの場合に問われているのはまさにこの点です。答えは、何から身を守りたいかによります。
DNS 暗号化が修正するもの — そして修正しないもの
二つのプロトコルを比較する前に、それぞれが実際に何を保護しているかを明確にしておく価値があります。古典的な DNS は、あなたのデバイスが調べるすべてのドメイン名を漏らします。example.com を訪問すると、ISP — またはネットワーク経路上のあらゆるネットワーク事業者 — は、ブラウザが最初の HTTPS リクエストを送る前の時点で、example.com へのクエリを見ることができます。その HTTPS リクエストの内容は暗号化されていますが、それに先行する DNS ルックアップは暗号化されていません。暗号化 DNS はその特定のギャップを塞ぎます。
修正されないもの：接続先の IP アドレスは依然として見えます。古いバージョンの TLS では、TLS の Server Name Indication（SNI）フィールドもハンドシェイク中にホスト名を漏らしていました — ただし Encrypted Client Hello（ECH）が TLS 1.3 でこの問題に対処しています。暗号化 DNS と ECH を組み合わせることで、明白な漏洩は塞がれます。ECH なしの場合、暗号化 DNS 単体では一つの漏洩を塞ぐだけで、TLS ハンドシェイク中に接続先ホスト名が依然として見えます。正直に言えば、暗号化 DNS は必要条件ではありますが十分条件ではありません。
DoT の仕組み — port 853 の専用チャンネル
DoT（DNS-over-TLS、RFC 7858 で定義）は概念的にシンプルな設計です。あなたのデバイスは port 853 で DNS サーバーへの TCP 接続を開きます。HTTPS を守るのと同じ TLS で TLS ハンドシェイクを行い、暗号化されたストリーム内に標準的な DNS クエリを送ります。DNS サーバーは標準的な DNS 応答を、同じく暗号化されたストリーム内で返します。ネットワーク上から見ると、見えるのは port 853 への TLS 接続だけです。
port 853 は IANA によって DoT に独占的に割り当てられているため、そのポート上のすべての TCP トラフィックは DoT であると明確に識別できます。ネットワーク事業者は DoT を容易に識別できます — ディープパケットインスペクションは不要で、宛先ポートを確認するだけです。DoT をブロックしたい場合は port 853 をドロップすればよい。宛先 DNS サーバーの IP をログに残したい場合も、それは簡単です。DoT は DNS であることを正直に示します。これは一部のユースケースでは美点ですが、他のユースケースでは弱点になります。
DoH の仕組み — Web トラフィックに隠された DNS
DoH（DNS-over-HTTPS、RFC 8484 で定義）は異なるアプローチを取ります。あなたのデバイスは DNS クエリを HTTP POST リクエスト（またはクエリパラメータ付きの GET リクエスト）として、DNS プロバイダーの HTTPS サーバー上の特定の URL に送ります。POST のボディにはバイナリ形式の DNS メッセージが含まれ、応答ボディにはバイナリ形式の DNS 応答が含まれます。これはすべて port 443 上の通常の HTTPS 接続で行われます — ブラウザが Web ページを読み込むのと同じポートです。
ネットワークの観点から見ると、DoH リクエストは同じサーバーへの通常の HTTPS リクエストと区別がつきません。接続は Web トラフィックに見えます。パケットサイズも Web トラフィックに見えます（最初のクエリ後、後続のクエリは同じ HTTP/2 または HTTP/3 接続を再利用します）。宛先 IP は汎用的なエンドポイントのものです — Cloudflare の 1.1.1.1 や Google の 8.8.8.8 は、同じ IP で DoH とその他の Web トラフィックの両方を提供しています。DoH を特定してブロックするには、ネットワーク事業者は特定のエンドポイントを識別してブロックしなければなりません。これはポートをブロックするよりもはるかに困難です。
ネットワーク可視性の違い
トランスポートの違いは可視性の違いを生み出します。DoT の場合、ネットワーク事業者（企業の IT 部門、ISP、学校、ホテル）は暗号化された DNS を使っていることを確認でき、どの DoT サーバーを使っているかを（宛先 IP で）把握でき、そのサーバーをブロックするかどうかを選択できます。DoH の場合、ネットワーク事業者は DNS プロバイダーの IP への暗号化された HTTPS トラフィックを見ることはできますが、DoH エンドポイントのブロックリストを積極的に管理していない限り、DoH と同じプロバイダーへの通常の HTTPS を区別できません。
これは予測可能な結果をもたらします。企業の IT 部門は長年 DoT を好んできました。ポートをきれいにブロックできるからです：port 853 をドロップすれば、DNS は組織のリゾルバーにフォールバックし、そこで監視とフィルタリングを行えます。同じ理由で DoH を嫌う傾向があります — DoH は彼らの可視性を回避するからです。消費者向けプライバシー支持者は同じ理由で DoH を好む傾向があります。異なるステークホルダーが同じアーキテクチャの決定から異なる結果を望んでいるのです。
ネットワークがブロックできるのはどちらか
DoT は簡単にブロックできます。port 853 はそのポートだけを使っています。ファイアウォールルールでドロップすれば完了です。多くの企業ネットワークがすでにそうしています。制限的な地域の多くのフィルタリングファイアウォールも同様です。DoT を使うようにデバイスを設定していて、そのネットワークが port 853 をブロックしている場合、OS またはアプリが平文 DNS にフォールバックするまで、デバイスの DNS クエリは失敗します — そして多くのものはサイレントにフォールバックします。
DoH はブロックがはるかに困難です。ブロックする唯一の方法は、すべての DoH エンドポイントを特定してブロックリストに載せることだからです。Cloudflare の 1.1.1.1 は最もよく知られており、通常はブロックリストに載っています。Google の 8.8.8.8 も同様です。しかし、独立して運営される DoH エンドポイントは増え続けています — curl の DoH wiki などの公開リストには数百のエンドポイントが載っています。DoH をグローバルにブロックしたいネットワーク事業者は、そのリストを常に最新に保ち、新しいエンドポイントに常に後れを取り続けることを受け入れなければなりません。制限的なネットワークの中には、トラフィックパターン分析で DoH を検出しようとするものもありますが（DoH にはリクエストサイズとタイミングに独特の特徴があります）、これは脆弱であり誤検知を生みます。
Mozilla の DoH ドキュメントは、DoH がネットワークによるブロックを困難にするというこの特性を、偶然ではなく意図的な設計目標として明示しています。同じ特性が、ネットワーク事業者が DNS の可視性をユーザーのプライバシー侵害ではなくセキュリティスタックの正当な一部と見なす企業環境で DoH を議論の的にします。
企業およびペアレンタルコントロールへの影響
DNS レベルのフィルタリング（ほとんどのペアレンタルコントロールソフトウェア、企業の「セーフブラウジング」フィルタリング、そして最もシンプルなマルウェアドメインブロッキングを動かしているもの）は、DNS クエリを傍受してブロック対象ドメインへのものをドロップするか、偽の応答を返すことで機能します。その仕組みの詳細は、DNS レベルフィルタリングの実際の仕組みの解説記事でご覧いただけます。
暗号化 DNS はこれを完全に回避します — DoT と DoH の両方が、ローカルネットワークのリゾルバーとは異なるリゾルバーにクエリを送るため、ローカルリゾルバーで適用されるフィルタリングは無意味になります。ペアレンタルコントロールベンダーの観点からは、これは問題です。ユーザーの観点からは、そのフィルタリングが正当なものか侵害的なものかによって完全に判断が変わります。多くの企業エンドポイント管理ツールは、ポリシーによってブラウザの DoH を無効にし、可視性を維持するために OS レベルの DNS 設定またはフルトラフィックインスペクションに依存しています。Apple の MDM 管理 iOS プロファイルには、まさにこのために設計された DoH/DoT 設定メカニズムが含まれています：企業は選択した暗号化 DNS リゾルバーを指定し、ユーザーがそれを変更できないようにすることができます。
家庭では、ブラウザで DoH をオンにすると、設定済みのルーターベースのコンテンツフィルタリングが回避されるというのが現実です。これが機能なのかバグなのかは、設定のどちら側にいるかによります。
パフォーマンス特性
DoT は通常、DoH よりも一クエリあたりのオーバーヘッドがわずかに低くなります。どちらのプロトコルも TLS を使いますが、DoT は各 DNS メッセージの周りにはるかに小さなラッパーを送ります — HTTP リクエスト行、ヘッダー、Content-Length、HTTP メソッドは不要です。DNS メッセージは TLS ストリームに直接入ります。それに対して DoH は各 DNS クエリを HTTP POST または GET の中にラップし、クエリあたり数十から数百バイトのオーバーヘッドが加わります。
このオーバーヘッドは、接続の再利用によってほぼ相殺されます。DoT と DoH の両方が多くのクエリにまたがって TLS 接続を開いたまま保つため、ハンドシェイクコストは一度だけ支払われます。HTTP/2 上の DoH は同じ接続でクエリを多重化し、HTTP/3（QUIC 上）はさらにレイテンシを削減します。実際のところ、最新のネットワークでは、ユーザーには両プロトコルのレイテンシは区別がつきません — 差はせいぜい一桁ミリ秒です。パフォーマンス上の理由でどちらかを選ぶ必要はありません。選択は可視性、制御、そして脅威モデルの問題です。
DoT vs DoH 一覧
| 特性 | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| ポート | 853（専用） | 443（HTTPS と共有） |
| RFC | RFC 7858（2016年） | RFC 8484（2018年） |
| トランスポート | TCP 上の Raw TLS | HTTPS（HTTP/2 または HTTP/3） |
| ネットワーク上での識別可否 | 可能 — port 853 は DoT に固有 | 不可能 — 通常の HTTPS に見える |
| ネットワークによるブロックのしやすさ | 容易（port 853 をドロップ） | 困難（エンドポイントブロックリストが必要） |
| ブラウザサポート | なし（ブラウザは DoT を実装していない） | Firefox、Chrome、Edge、Safari すべてサポート |
| OS サポート | Android 9+、iOS 14+、macOS 11+、Linux（systemd-resolved） | Android 9+、iOS 14+、macOS 11+、Windows 11+ |
| 企業での可視性 | ポートで可視化できる。監視・ブロックが容易 | ポートベースの監視を回避。エンドポイントインスペクションが必要 |
| 一クエリあたりのレイテンシオーバーヘッド | 低い（最小限のラッパー） | やや高い（HTTP ヘッダー）。HTTP/2 多重化で実用上は無視できる |
| 検閲への耐性 | 低い（ポートでブロック可能） | 高い（port 443 は現代の Web に不可欠） |
どちらを使うべきか — 3つのシナリオ
「どちらのプロトコルが優れているか」は、達成しようとしていることにまったく依存します。具体的な答えを持つ3つの具体的なシナリオを示します。
シナリオ1：敵対的または信頼できないネットワーク上の個人デバイス
カフェ、ホテル、空港、友人の Wi-Fi。脅威モデルは、ローカルネットワーク事業者があなたの DNS を観察または改ざんするというものです。暗号化自体にはどちらのプロトコルも機能します。DoH の方が好ましいのは、敵対的なネットワークがブロックするのがはるかに困難だからです。port 853 をドロップするネットワーク上で DoT を使うと、クエリはサイレントに port 53 の平文にフォールバックします（多くの OS クライアントはこのようにオープンに失敗します）— 守ろうとしていたものをすべて漏らしてしまいます。DoH はほぼ常にそのエンドポイントに到達します。
シナリオ2：子どものデバイスを管理するホームネットワーク
子どもたちのデバイスにフィルタリング DNS リゾルバー（NextDNS、OpenDNS Family Shield、Cloudflare for Families）を使わせ、それを迂回できないようにしたい場合です。DoT の方が実は使いやすいです — 特定の DoT リゾルバーを使うようにデバイスを設定すれば、子どもはブラウザの設定を簡単に変えて別の DNS を使うことができません。ブラウザの DoH は企業/MDM ポリシーで無効にするか、カナリアドメインを設定することで無効にできます。DoT か DoH かの選択は、個々のアプリに選択させるのではなく OS レイヤーでデバイスレベルの DNS を設定することほど重要ではありません。
シナリオ3：すでに VPN を使っている場合
VPN を使っていれば、ローカルネットワークはどちらの方式でも DNS クエリを見ることができません — VPN トンネルが DNS を含むすべてを暗号化するからです。重要な問いは、VPN が内部でどの DNS リゾルバーを使っているか、そしてそのアップストリームリゾルバーへの暗号化 DNS をサポートしているかどうかになります。最新の VPN（Casper's Cloak を含む）はほとんどが内部で暗号化 DNS を使い、応答をトンネル経由で返す前にリゾルバーで脅威ドメインフィルタリングを適用します。この構成では、DoT vs DoH はほぼ実装の詳細です。重要なのは、リゾルバーが ISP でなく、クエリをログに残さないことです。
両プロトコルが回避している信頼の問い
DoT と DoH はどちらも、信頼の対象をローカルネットワーク事業者から、選択した暗号化 DNS プロバイダーに移します。Cloudflare、Google、Quad9、NextDNS、ControlD — これらの企業はそれぞれ、あなたが送るすべての DNS クエリを見ています。彼らへの暗号化は、彼ら自身からのプライバシーを意味しません。ISP に DNS を見られないようにしたいなら、暗号化 DNS は問題を解決します。いかなる第三者にも DNS を見られたくないなら、どちらのプロトコルも助けになりません。自分自身の再帰リゾルバーを運用する必要があり、それはそれ自体で一つのプロジェクトです。
信頼するリゾルバーに求められること：明確なログポリシー、第三者による監査、クエリの最小化サポート（アップストリームの権威サーバーにクエリの必要な部分だけが見えるようにするもの）、そして DNSSEC 検証。主要な公開 DoH/DoT プロバイダーはすべてポリシーを公開しています。読みましょう。この点についての詳細なガイドは2026年の DoH 解説記事にあります。
結論
DoT と DoH は同じ根本的な問題 — DNS の平文がブラウジング先をネットワークに漏らすこと — を、二つの異なるアーキテクチャ戦略で解決します。DoT は誠実な設計です：専用ポートで、識別しやすく、管理しやすく、ブロックしやすい。DoH はカモフラージュされた設計です：HTTPS トラフィックに隠れ、エンドポイントブロックリストなしでは識別が困難で、大規模なブロックが難しい。
敵対的なネットワーク上の消費者には、DoH が正しい選択です。実際にエンドポイントに到達できる方だからです。DNS の可視性が必要な企業には、DoT がより協調的な選択です。自宅でフィルタリング DNS を運用している人には、DoT の方が設定しやすく、ユーザーがアプリレベルで回避するのが難しくなります。VPN ユーザーには、選択はほぼ見えません — VPN クライアントが処理します。
本当の問いは「DoT か DoH か」であることはほとんどありません — 「どのリゾルバーを信頼しているのか、そのログポリシーはどうなっているのか」です。信頼できるリゾルバーを選び、ブラウザごとではなくシステム全体で設定し、DNS リークテストで実際に設定が正しくできているかを確認してください。そのリゾルバーへの通信プロトコルは、相手先エンドのエンティティのポリシーよりも重要ではありません。