DNS over HTTPS（DoH）とは何ですか？

DNS クエリを HTTPS 経由で暗号化して送信し、通信の傍受や改ざんを防ぐプロトコル。Chrome・Firefox が標準対応。

DNS

DNS over HTTPS（DoH）

Q: DNS over HTTPS（DoH）の概要について教えてください

DNS over HTTPS（DoH） は、DNS クエリを HTTPS プロトコル経由で暗号化して送信する仕組みです。RFC 8484（2018年10月）で標準化されました。従来の DNS は UDP ポート 53 を使って平文でクエリを送受信するため、通信経路上の第三者がどのドメインを問い合わせたかを傍受できます。DoH はこの問題を解消し、DNS クエリの機密性と完全性を HTTPS（TLS）で保護します。

2026年3月10日更新

概要

DNS over HTTPS（DoH） は、DNS クエリを HTTPS プロトコル経由で暗号化して送信する仕組みです。RFC 8484（2018年10月）で標準化されました。従来の DNS は UDP ポート 53 を使って平文でクエリを送受信するため、通信経路上の第三者がどのドメインを問い合わせたかを傍受できます。DoH はこの問題を解消し、DNS クエリの機密性と完全性を HTTPS（TLS）で保護します。

従来の平文 DNS では、ISP やネットワーク管理者、公衆 Wi-Fi の攻撃者がユーザーの閲覧先ドメインを容易に把握できました。また、経路上で DNS 応答を差し替える中間者攻撃（DNS スプーフィング）のリスクもあります。DoH はクエリと応答の双方を TLS で暗号化するため、これらの脅威を排除します。

DoH と類似のプロトコルとして DNS over TLS（DoT、RFC 7858、2016年）があります。両者は DNS 通信を暗号化するという目的は同じですが、使用するポートとプロトコル層が異なります。DoT は専用のポート 853 を使い、トランスポート層で TLS を適用します。DoH は HTTPS の標準ポート 443 を使い、アプリケーション層で暗号化します。ポート 443 は通常の Web 通信と同じであるため、DoH のトラフィックは他の HTTPS 通信と区別しにくく、ネットワーク管理者による選択的なブロックが困難です。

Labee Dev Toolbox の DNS API は DoH を使って外部のリゾルバーからレコードを取得します。ユーザーが DNS Checker で入力したドメインの名前解決は、すべて DoH 経由で行われます。

仕組み

DoH のプロトコル構造、ワイヤーフォーマットと JSON API の違い、通信の流れ、DoT や DNSSEC との比較を説明します。

プロトコルの構造

DoH は既存の HTTPS インフラの上に DNS メッセージを載せる設計です。RFC 8484 では、DoH サーバーが URI テンプレートを公開し、クライアントがその URI に HTTP リクエストを送る形式を定めています。

クライアントは GET メソッドまたは POST メソッドでクエリを送信できます。GET の場合、DNS ワイヤーフォーマットのメッセージを base64url エンコードし、dns パラメーターとして URI に付加します。POST の場合、DNS メッセージをリクエストボディにそのまま含めます。

GET /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Accept: application/dns-message

POST /dns-query HTTP/2
Content-Type: application/dns-message
Accept: application/dns-message

[DNS ワイヤーフォーマットのバイナリデータ]

レスポンスのコンテンツタイプは application/dns-message です。RFC 8484 で定義されているのはこのワイヤーフォーマットのみです。

JSON API 形式

ワイヤーフォーマットとは別に、Cloudflare や Google は独自の JSON API 形式も提供しています。Accept: application/dns-json ヘッダーを指定すると、人間が読みやすい JSON 形式でレスポンスが返ります。

# Cloudflare の JSON API でドメインを問い合わせる
curl -s -H "Accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

{
  "Status": 0,
  "Answer": [
    {
      "name": "example.com",
      "type": 1,
      "TTL": 3600,
      "data": "93.184.216.34"
    }
  ]
}

JSON API 形式は RFC 8484 の範囲外であり、プロバイダーごとに実装が異なります。安定した互換性が求められる場合は、ワイヤーフォーマット（application/dns-message）を使用します。

Labee Dev Toolbox の DNS API も、この JSON API 形式（application/dns-json）で DoH リクエストを送信しています。

通信の流れ

DoH を使った名前解決は次の手順で進みます。

クライアント（ブラウザーや OS）が DoH サーバーへの TLS ハンドシェイクを行い、HTTPS 接続を確立する
クライアントが DNS クエリを HTTP リクエストとして送信する
DoH サーバー（再帰リゾルバー）がクエリを受け取り、通常の DNS 解決プロセスを実行する
DoH サーバーが DNS 応答を HTTP レスポンスとして暗号化して返す

この通信全体が TLS で保護されるため、経路上の第三者はクエリの内容も応答の内容も読み取れません。接続先の DoH サーバーの IP アドレスは見えますが、どのドメインを問い合わせたかは暗号化されています。

DoH と DoT の比較

項目	DoH（RFC 8484）	DoT（RFC 7858）
使用ポート	443（HTTPS 共用）	853（専用）
プロトコル層	アプリケーション層（HTTP/2 + TLS）	トランスポート層（TLS）
トラフィックの識別	HTTPS と区別困難	ポート 853 で識別可能
ブロック耐性	高い（443 を塞ぐと Web 通信も停止）	低い（853 だけ塞げる）
ブラウザー対応	主要ブラウザーが標準対応	OS レベルでの対応が中心
RFC 発行年	2018年	2016年

企業ネットワークで DNS トラフィックを監視・制御する必要がある場合は DoT が選ばれる傾向にあります。エンドユーザーのプライバシー保護を優先する場合は DoH が適しています。

DNSSEC との違い

DoH と DNSSEC は保護する対象が異なります。

DoH は「通信経路」を保護します。クライアントとリゾルバーの間の DNS クエリ・応答を暗号化し、第三者による傍受を防ぎます。ただし、リゾルバーが受け取った DNS データ自体が正当かどうかは検証しません。

DNSSEC は「データの完全性と出自」を保護します。権威サーバーが DNS レコードにデジタル署名を付与し、リゾルバーが署名を検証することで、レコードが改ざんされていないことを確認します。ただし、通信自体は暗号化しません。

両者は補完関係にあります。DoH で通信経路を暗号化し、DNSSEC でデータの正当性を保証することで、DNS クエリの全行程を保護できます。

確認方法

自分の DNS クエリが DoH 経由で送信されているかを確認するには、ブラウザーの設定を確認するのが最も直接的です。

Firefox:  設定 → プライバシーとセキュリティ → DNS over HTTPS
Chrome:   設定 → プライバシーとセキュリティ → セキュリティ → 安全な DNS を使用する
Edge:     設定 → プライバシー、検索、サービス → セキュリティ → 安全な DNS を使用する

コマンドラインから DoH エンドポイントに直接リクエストを送ることで、DoH の動作を確認できます。

# Cloudflare DoH に curl で問い合わせる（JSON API 形式）
curl -s -H "Accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

# Google DoH に curl で問い合わせる（JSON API 形式）
curl -s "https://dns.google/resolve?name=example.com&type=A"

dig コマンドは従来の平文 DNS プロトコルを使用するため、DoH ではなく UDP/TCP ポート 53 で通信します。DoH 経由の問い合わせには curl を使います。

# 比較: dig は平文 DNS（ポート 53）
dig A example.com @1.1.1.1

# DoH 経由: curl で HTTPS ポート 443
curl -s -H "Accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、DNS over HTTPS を使って外部のリゾルバーから見た結果を取得できます。レスポンスが返れば DoH 経由での名前解決が正常に機能していることを意味します。

curl "https://labee.dev/api/dns?domain=example.com&type=A"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "A": [
        { "address": "93.184.216.34", "ttl": 3600 }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

data.records に各レコードタイプの結果が含まれます。meta.responseTime は DoH 経由での名前解決にかかった時間（ミリ秒）です。

よくある問題

DoH の導入時には、社内 DNS との競合やプライバシーの集中先の変化が問題になることがあります。

DoH を有効にしたら社内サイトにアクセスできなくなった

企業ネットワークでは、社内 DNS サーバーがイントラネットのドメイン名を解決しています。ブラウザーが DoH を有効にすると、DNS クエリが社内 DNS サーバーではなく外部の DoH プロバイダー（Cloudflare や Google）に送られます。外部のリゾルバーは社内専用のドメインを解決できないため、名前解決に失敗します。

Firefox の DoH 設定で「最大保護」を選択している場合、社内 DNS へのフォールバックが行われません。「デフォルト」や「強化」であれば、DoH で解決できない場合に OS の DNS 設定にフォールバックします。

企業ネットワークの管理者は、use-application-dns.net のカナリアドメインを使って Firefox の DoH 自動有効化を抑制できます。このドメインの A レコードが存在しない場合、Firefox は DoH を自動的に無効化します。

DoH プロバイダーへのプライバシー集中

DoH は経路上の傍受を防ぎますが、DoH プロバイダー自身はすべてのクエリ内容を把握できます。従来の平文 DNS では ISP がクエリを見ていましたが、DoH を使うと ISP の代わりに DoH プロバイダーにクエリ情報が集中します。プライバシーの観点では、ISP からDoH プロバイダーへの信頼先の移動にすぎないという指摘があります。

Cloudflare はクエリログを 24 時間 で削除するポリシーを公開し、毎年第三者機関による監査を受けています。プロバイダー選択の際はプライバシーポリシーとログ保持期間を確認してください。

ネットワーク管理者による DNS 制御が効かなくなる

企業や学校のネットワークでは、DNS ベースのコンテンツフィルタリングやセキュリティ対策を導入していることがあります。ユーザーが DoH を有効にすると、これらの DNS レベルの制御を迂回できてしまいます。ポート 443 は通常の HTTPS 通信にも使われるため、DoH トラフィックだけを選択的にブロックすることは困難です。

この問題に対処するため、企業向け DNS サービス（Cloudflare Gateway、Cisco Umbrella 等）は組織内 DoH エンドポイントを提供しています。組織管理の DoH エンドポイントを使用することで、暗号化の恩恵を受けつつ DNS ポリシーを維持できます。

パフォーマンスへの影響

DoH は HTTPS 接続を確立するための TLS ハンドシェイクが必要です。初回接続時には、平文 DNS と比べて数十ミリ秒の遅延が加わります。ただし、HTTP/2 の接続再利用（コネクションプーリング）により、2 回目以降のクエリでは接続確立のオーバーヘッドは発生しません。

実運用上、DoH による遅延がユーザー体験に影響を与えることはほとんどありません。Cloudflare や Google の DoH エンドポイントはグローバルに分散配置されており、応答時間は従来の平文 DNS と同等かそれ以下です。

ブラウザーと OS の対応状況

主要ブラウザーは DoH にネイティブ対応しています。

Firefox は DoH の早期推進者です。2020年2月に米国のユーザーに対して DoH をデフォルト有効にしました。その後、2021年にカナダ、2022年3月にロシアとウクライナでもデフォルト有効化されています。デフォルトの DoH プロバイダーは Cloudflare です。ユーザーは設定画面から保護レベル（デフォルト / 強化 / 最大保護 / オフ）を選択できます。

Chrome は 2020年5月に DoH のデフォルト有効化を開始しました。Chrome のアプローチは Firefox と異なり、OS に設定されている DNS プロバイダーが DoH 対応であれば自動的に DoH へアップグレードする方式です。DNS プロバイダー自体は変更しません。

Safari はブラウザー単体での DoH 設定 UI を提供していません。macOS や iOS の構成プロファイルを通じて DoH を設定するか、Cloudflare の 1.1.1.1 アプリなどを使用します。

OS レベル では、Windows 11 が設定画面から DoH 対応の DNS プロバイダーを選択できます。macOS と iOS は構成プロファイルで対応しています。Android 9 以降は「プライベート DNS」設定で DoT に対応しており、DoH は Android 13 から対応が進んでいます。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す