DNS over HTTPS (DoH) 完全解説：ブラウザ完結型暗号化がISPの閲覧追跡を阻止する仕組み
RFC 8484規格、DNSSEC暗号署名検証、エッジリゾルバの遅延特性を徹底解剖。
MindLucid セキュリティチーム
コアネットワークアーキテクチャ部門
ブラウザ内で今すぐ検証（サーバーアップロード一切なし）
プライバシーとRFC 8484仕様
従来のDNS問い合わせは平文のUDPポート53で送信され、ISPやローカル傍受者に閲覧履歴を監視される恐れがありました。DoHはTLS 1.3（ポート443）で全通信を暗号化します。
完全ブラウザ内ローカル実行
このツールはCORS対応DoHプロトコルを使い、Cloudflare (1.1.1.1) やGoogle (8.8.8.8) と直接通信します。中継サーバーは一切存在しません。
各DNSレコードの役割
A: IPv4アドレス • AAAA: IPv6アドレス • MX: メール配送先 • TXT: SPF/DKIM検証 • CNAME: エイリアス別名 • NS: 権威ネームサーバー。
従来の平文DNSが抱える構造的欠陥 (Port 53)
1980年代に策定されたドメインネームシステム（RFC 1034 / 1035）は、暗号論的機密性よりも通信の到達性と軽量性を最優先していました。その結果、すべてのDNS名前解決クエリはUDPポート53において暗号化されない平文で標準化されました。
端末がドメインにアクセスするたび、訪問先ホスト名が書かれた平文パケットがローカルWi-Fi、ホームルーター、およびインターネットプロバイダ（ISP）を通過します。多くの国やプロバイダにおいて、これらのデータはマーケティング目的で収集・販売されたり、検閲による強制リダイレクトの標的となります。
RFC 8484規格（DoH）がもたらしたセキュリティ革新
2018年10月、IETFはDNS Queries over HTTPSを定義する RFC 8484 を正式に批准しました：
- TLS 1.3 トンネリング: すべてのDNS質問と応答は、ポート443の既存HTTPSセッション内にカプセル化され暗号化されます。
- 通常Webトラフィックとの完全同化: DoHパケットは一般的なWebアクセスと全く同じポート番号と暗号スイートを使用するため、中継ファイアウォールがDNSクエリとWeb通信を識別・遮断することは不可能です。
- HTTP/2およびHTTP/3による多重化: 単一の多重化TCPまたはQUIC接続上で複数のDNS名前解決を並行パイプライン処理し、ハンドシェイク遅延を最小化します。
DNSSEC：機密性と完全性の両立
DoHが提供するものが「機密性（誰が何を照会したかを隠す）」であるのに対し、DNSSECが提供するのは「完全性（回答が改ざんされていない証明）」です。ゾーンがDNSSECで署名されている場合、暗号公開鍵（RRSIG / DSレコード）によってIANAルートゾーンに至る信頼の連鎖が検証されます。
下記インタラクティブツールでDoHを即時体験
ブラウザ内から直接Cloudflare（1.1.1.1）およびGoogle（8.8.8.8）の公開DoHエンドポイントに通信し、中継サーバーへのログ送信なしにセキュアな名前解決を体感してください。
よくある質問（FAQ）
なぜ従来の平文DNSはWeb閲覧履歴を漏洩させるのですか？
標準的なDNSはUDPポート53で平文通信を行うため、同一Wi-Fi内の盗聴者やISPルーターが照会ドメイン名をそのまま記録・分析できるためです。
DoHは接続先WebサーバーのIPアドレスも隠蔽しますか？
DoHは名前解決フェーズを完全暗号化します。さらにEncrypted Client Hello（ECH）と併用することで、SNI漏洩を防ぎアクセス先全体の完全な秘匿が可能になります。
ソフトウェアをインストールせずにブラウザ上でDoHをテストできますか？
はい。本記事に埋め込まれたインタラクティブツールを使用すれば、クライアントサイドから直接暗号化名前解決を試すことができます。