---
title: 'DNSプライバシー: DoH, DoT, DoQ, ODoH'
url: https://doc.liz6.com/ja/networking/04-DNS/03-dns-privacy-doh-dot-doq-odoh
locale: ja
area: networking
tags:
- networking
- DNS
date: 2026-06-30
modified: 2026-07-16
description: DNSは元々平文プロトコルであり、ISPや中継ネットワークはどのドメインが照会されたかを確認できる。DoT/DoH/DoQはDNSクエリを暗号化チャネルに格納し、ODoHはさらにプロキシとリゾルバーの分離により、「誰が照会しているか」と「何を照会しているか」のプライバシー分離を実現する。4つのプロトコルは、プライバシー強度、デプロイメントモード、ミドルウェア互換性の点でそれぞれトレードオフがある。
---

# DNSプライバシー: DoH, DoT, DoQ, ODoH

> DNSは元々平文プロトコルであり、ISPや中継ネットワークはどのドメインが照会されたかを確認できる。DoT/DoH/DoQはDNSクエリを暗号化チャネルに格納し、ODoHはさらにプロキシとリゾルバーの分離により、「誰が照会しているか」と「何を照会しているか」のプライバシー分離を実現する。4つのプロトコルは、プライバシー強度、デプロイメントモード、ミドルウェア互換性の点でそれぞれトレードオフがある。

## 概要

DNSは当初、平文プロトコル（UDPポート53）であり、ISPや中継ネットワークは、Webサイトの内容自体がHTTPSで暗号化されていても、あなたがどのドメインを照会したかを見ることができる。DoT（DNS over TLS）とDoH（DNS over HTTPS）は、DNSクエリを暗号化チャネルに格納し、機密性を提供する。DoHは、標準的なHTTPSトラフィックと見分けがつかないため、特にプライバシーを重視するユーザーに人気がある。DoQ（DNS over QUIC）は、さらにハンドシェイクの遅延を削減する。ODoH（Oblivious DoH）は、プロキシとリゾルバーの分離により、「誰が照会しているか」と「何を照会しているか」のプライバシー分離を実現する。

## DoT: DNS over TLS (ポート853)

DNSのワイヤーフォーマットは、TLS接続上で直接送信される。独立したポート（853）を使用するため、ネットワーク管理者は容易に識別してQoS分類を行うことができるが、同時にブロックされやすいという欠点もある。

```
クライアント → サーバー ポート853:
  TLSハンドシェイク (ECH有効時 + 暗号化SNI付きで1-RTT)
  → 接続確立後: 2バイトの長さプレフィックス + DNSメッセージ (RFC 1035 ワイヤーフォーマット)
     長さ: ビッグエンディアン、プレフィックス自身は含まない (最大65535)
```

## DoH: DNS over HTTPS (ポート443)

DNSは標準的なHTTPSトラフィックに混在しており、Webサイトとのトラフィックと見分けがつかない。

```
クライアント → https://dns.example.com/dns-query:
  POST: Content-Type: application/dns-message
         Body: DNSワイヤーフォーマット (RFC 1035と同様)
  GET:  ?dns=<base64url(DNSワイヤーフォーマット)>

  HTTP/2: ストリーム多重化 → 複数のクエリが1つのTCP接続を共有
  HTTP/3: QUIC → キャッシュされたDNSリゾルバーで0-RTT

コンテンツネゴシエーション (オプション):
  Accept: application/dns-message → IDNAワイヤーフォーマット (バイナリ、デフォルト)
  Accept: application/dns-json → JSON (Google/Cloudflare固有)
```

## DoQ: DNS over QUIC (ポート853)

DoQはTCP+TLSの代わりにQUICを使用し、DoTのハンドシェイク遅延とTCPのHOL（Head-of-line）ブロッキング問題を解決する。

```
QUIC接続 (UDP 853):
  ストリーム0: クライアント開始、双方向 → DNSメッセージ
  ストリーム4: クライアント開始、単方向 → サーバーがデータを送信するために使用
  ストリーム8: クライアント開始、単方向 → クライアントがデータを送信するために使用

各ストリーム: STREAMフレームにDNSメッセージを含む (長さプレフィックス不要、QUICストリームが境界を自動処理)
```

## ODoH (Oblivious DNS over HTTPS, RFC 9230)

問題点: DoHでも「誰が何を照会しているか」は依然として露出する。リゾルバーはクライアントIPとDNSクエリの両方を見ることになる。

ODoHはプロキシとリゾルバーを分離する。

```
クライアント → プロキシ (Oblivious Proxy):
  暗号化されたPOST https://proxy/dns-query
  Body: 暗号化されたDNSクエリ (リゾルバーのHPKE公開鍵で暗号化)
  → プロキシはクライアントIPを知るが、クエリ内容は見えない

プロキシ → ターゲット (Oblivious Target = DNSリゾルバー):
  暗号化されたPOST https://resolver/dns-query
  Body: 暗号化されたDNSクエリ (同じく、プロキシは復号できない)
  → ターゲット/リゾルバーはクエリ内容は見るが、クライアントIPはわからない (プロキシのIPしか見えない)

プロキシとターゲットは共謀してはならない (共謀すると、依然として追跡可能になる)
```

## 4つのプロトコル比較

| | ポート | 転送プロトコル | ハンドシェイク | ブロック容易性 | プライバシー (クエリ) | プライバシー (クライアントIP) |
|---|---|---|---|---|---|---|
| Do53 | 53 UDP | UDP | 0 | 極めて低い | なし | なし |
| DoT | 853 | TCP+TLS | 1-2 RTT | 高い (独立ポート) | 部分的 (TLS) | なし |
| DoH | 443 | HTTP/2 または /3 | 1-2 RTT (h2), 0-1 RTT (h3) | 極めて低い (HTTPSと混在) | 部分的 (HTTPS) | なし |
| DoQ | 853 | QUIC/UDP | 0-1 RTT | 中程度 | 部分的 (QUIC) | なし |
| ODoH | 443 | HTTP + HPKE | 2 RTT (プロキシ経由後、リゾルバーへ) | 低い | あり (二重) | あり (リゾルバーは不可視) |

## 参考

- **RFC**: 7858, 8484, 9250, 9230
- **AdGuard**: adguard-dns.io/encryption.html

*キーワード: DoH, DoT, DoQ, ODoH, DNSプライバシー, 暗号化DNS, HPKE, オブリビオスプロキシ*