DNS over HTTPS / over TLS：名前解決の暗号化

平文 DNS が漏らしているもの

DNS の名前解決 は伝統的に UDP/53（一部 TCP/53）の平文で行われます。スタブリゾルバからフルサービスリゾルバへ送るクエリも、その応答も暗号化されておらず、経路上の誰もが中身を読めます。ここで漏れるのは「どのサイトへ通信したか」という強いプライバシー情報です。仮に接続先が HTTPS で暗号化されていても、その直前に引いた www.example.com という名前そのものが平文 DNS で観測できれば、行き先は丸わかりです。

さらに深刻なのは改ざんです。平文 UDP には認証がなく、攻撃者が偽の応答を本物より先に注入すればクライアントは騙されます。これがキャッシュポイズニングや DNS スプーフィングの根です。

DoT：ポート 853 を専有する素直な方式

DoT（DNS over TLS, RFC 7858） は最も素直です。クライアントとリゾルバの間に TLS セッションを張り、その中を従来とほぼ同じ DNS メッセージ（TCP/53 と同じ2バイト長プレフィックス付きフレーミング）が流れます。違いは専用ポート 853 を使う点だけです。

[stub] --TCP--> [resolver:853]
  1) TCP 3-way handshake
  2) TLS handshake（証明書でリゾルバを認証）
  3) この TLS の中で DNS クエリ/応答を平文時と同じ形式で送受信

ポートを分けた設計の狙いは明快です。853 を見れば「これは暗号化 DNS だ」と一目で分かるため、リゾルバ側の実装も切り分けやすく、ネットワーク管理者も識別・ポリシ適用がしやすい。半面、その識別しやすさは検閲やフィルタにとっても容易を意味します。ファイアウォールが 853 を落とせば DoT は丸ごと止まり、クライアントは平文 53 にフォールバックしかねません。

DoH：HTTPS に紛れさせる方式

DoH（DNS over HTTPS, RFC 8484） は別の戦略を採ります。DNS メッセージを HTTP/2 以降 のリクエストに載せ、通常の HTTPS と同じポート 443 で送ります。GET ならクエリを base64url した ?dns=... を、POST ならボディに application/dns-message（ワイヤ形式の生 DNS メッセージそのもの）を入れます。

POST /dns-query HTTP/2
Host: doh.example.net
Content-Type: application/dns-message
Accept: application/dns-message

<ワイヤ形式の DNS クエリ（バイナリ）>

ポイントは、ネットワークから見ると DoH トラフィックが普通の Web アクセスと区別しづらいことです。443 の TLS の中身は暗号化されており、SNI などを除けばパケットの見た目は他の HTTPS と同じ。これが「HTTPS 偽装」と呼ばれる性質で、ポートやプロトコルでのブロックを難しくします。

両者の本質的な違いは暗号強度ではなく**「見えやすさ」の設計思想**です。DoT は秘匿しつつ識別可能に、DoH は秘匿しつつ識別困難に振っています。

暗号化されるのは「最初の1区間」だけ

ここが最大の誤解ポイントです。DoT/DoH が暗号化するのはスタブリゾルバ ⇔ フルサービスリゾルバの区間に限られます。リゾルバが TLS を解いた先で、ルートや TLD、権威サーバーへ反復問い合わせする部分は依然として平文 53 が主流です。

[端末] ==DoH/DoT(暗号)==> [リゾルバ] --平文53--> [ルート/TLD/権威]
        ↑ここだけ保護              ↑ここは従来どおり露出しがち

つまり保護されるのは「端末から最初に頼るリゾルバまで」であり、その先のインターネット側の観測者やリゾルバ運営者自身からは引いた名前が見えます。むしろ DoH/DoT で特定の大規模リゾルバへ集約すると、これまで各 ISP に分散していた「誰が何を引いたか」の全履歴が、少数の運営者に集中します。盗聴者は変わるが、信頼の置き先が一点に寄るという集中化のトレードオフです。

Oblivious DNS（ODoH）：送信元と内容を分離する

集中化の核心は「リゾルバが『どの IP が』『どの名前を』引いたかを同時に知る」点にあります。これを断つのが Oblivious DoH（ODoH, RFC 9230） です。発想は単純で、クエリ内容を暗号化したままプロキシを1段挟み、二つの知識を別々の主体に分けます。

[端末] --(リゾルバ公開鍵で暗号化したクエリ)--> [Oblivious Proxy]
                                                   │ 送信元IPは見えるが
                                                   │ 中身は復号できない
                                                   ▼
                                          [Oblivious Target = リゾルバ]
                                            中身は復号できるが
                                            送信元IPはプロキシのものしか見えない

• プロキシは送信元 IP を見るが、クエリ本文はリゾルバの公開鍵で暗号化済みのため内容を読めない。
• ターゲット（リゾルバ）は復号して名前を知るが、接続元はプロキシなので本当の端末 IP を知らない。

「IP を知る者」と「名前を知る者」を分離し、両者が結託しない限り「誰が何を引いたか」は誰にも復元できません。これは プロキシ の中継に、エンドツーエンド暗号（HPKE による封筒暗号）を重ねて実現します。コストはプロキシ1段ぶんの遅延と、プロキシ・ターゲットが共謀しないという信頼前提です。

一段で言うと

DoT と DoH は「端末からリゾルバまでの DNS を TLS で包み、盗聴と途中差し替えを防ぐ」点で同じで、違いは「853 で名乗るか（DoT）、443 で HTTPS に紛れるか（DoH）」という可視性の設計だけです。ただし暗号化は最初の1区間に限られ、リゾルバ運営者にはクエリが集中するため、秘匿性の改善と引き換えに信頼の一点集中という代償が生じます。その集中を緩めるのが、IP と名前を別主体に分ける Oblivious DNS です。検証には kdig +tls や dig の DoH 対応版でハンドシェイクと証明書を確認し、どの区間が暗号化され、どこから平文に戻るかを必ず切り分けてください。