DNS over HTTPSとは？DoHの仕組みとDoT・DoQとの違い、設定手順を実装者向けに解説

DNS over HTTPS（DoH）は、これまで平文のまま流れていた名前解決の問い合わせを、HTTPSの中に入れて運ぶ方式です。使うポートは443番。つまり普通のWeb通信と見分けがつかない形になります。この記事では、RFC 8484が定める仕組み、853番を使うDoTやDoQとの構造的な差、暗号化しても残る可視性、WindowsとブラウザでのDoH設定、そして社内ネットワークで何が壊れるかを実装視点で整理しました。見送るべき条件も代案とセットで示します。

まとめ｜DoHが効く構成と平文DNSのままで足りる境界

先に結論を置きます。DoHが効くのは、信頼できないネットワークを経由して名前解決を行う端末です。公衆Wi-Fi、社外に持ち出すノートPC、来訪者用のセグメント。この条件なら、経路上の第三者が接続先ドメインを覗いたり、応答を差し替えたりする余地が確実に減ります。

一方で、閉域網の中だけで完結するサーバ群や、社内権威DNSしか参照しない業務端末には、DoHを持ち込む理由が薄い。むしろ社内名の解決が外部のリゾルバへ流れて壊れる副作用のほうが大きくなります。Active Directory に参加した端末でDoHを必須化する設定は、Microsoft自身が避けるよう案内している構成です。

もうひとつ、期待値の調整が要ります。DoHはDNSの経路を隠すだけで、接続先そのものを隠しません。TLSハンドシェイクのSNIや宛先IPアドレスは経路上に残ったままです。「DoHを入れたので通信内容が保護された」と説明してしまうと、後で必ず食い違いが出ます。守れる範囲を切り分けて伝えるところまでが設計の仕事だと考えてください。

DNS over HTTPSの定義とRFC 8484｜名前解決をHTTPSに載せる仕組み

名前は「HTTPSでDNSを引く」とそのままですが、中身は既存のDNSメッセージを別の運び方へ移し替えた仕様です。

平文のDNSクエリが抱える課題とDoHが解こうとした問題の範囲

従来のDNSは、53番ポートのUDPまたはTCPで、問い合わせも応答も平文のまま流れます。名前解決の基本的な流れとdigやnslookupでの確認方法を押さえておくと、どの区間が露出しているのかを切り分けやすくなります。露出する区間は、端末からフルサービスリゾルバまでの経路。ここを通る誰もが「どのドメインを引いたか」を読めます。

読めるだけではありません。応答を書き換えて別のIPアドレスへ誘導する余地も残る。DoHは、この端末とリゾルバの間の1区間だけを、HTTPSで包んで塞ぐ仕様です。逆に言えば、リゾルバから権威サーバへ向かう上流の区間は対象外。ここは別の仕組みが受け持ちます。

URIテンプレートとdns-message形式｜GETとPOSTの使い分け方

仕様は RFC 8484「DNS Queries over HTTPS (DoH)」（2018年10月・Proposed Standard）です。クライアントはあらかじめ設定されたURIテンプレートに対してHTTPSで要求を出します。仕様上、リゾルバを動的に見つけ出す動作はここには含まれず、事前設定が前提です。土台の暗号化そのものはTLSの仕組みとバージョン選定に依存し、HTTP/2の使用が推奨されています。

運ぶ中身はRFC 1035のワイヤ形式そのままで、MIME型は application/dns-message、上限は65,535バイト。GETとPOSTの両方を実装することが必須要件です。GETではクエリを dns という変数へパディングを除いたbase64urlで載せ、POSTではボディへエンコードせずに置きます。

curl -s -H 'accept: application/dns-message' \
  'https://dnsserver.example.net/dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' \
  --output resp.bin

上はRFC 8484が例示しているGET形式のクエリ文字列です。実装を確かめるときは、まずこの形で200が返るかを見るのが早い。返らない場合はテンプレートの綴りかacceptヘッダのどちらかを疑ってください。

HTTPのキャッシュとDNSのTTL｜二重のキャッシュが起こす食い違い

見落とされやすいのがキャッシュの二重構造です。DNSにはレコードごとのTTLがあり、HTTPにはHTTP側の鮮度制御がある。RFC 8484は、HTTPレスポンスの鮮度寿命をDNS応答の最小TTL以下に設定し、TTLを算出する際はAgeヘッダの値を差し引くよう求めています。

この対応を怠ると、権威側でレコードを切り替えたのに端末が古いIPアドレスを掴み続ける事故が起きます。フェイルオーバーやBlue-Green切り替えでTTLを短く設計していても、途中のHTTPキャッシュが効いていれば意図した秒数では切り替わりません。自前でDoHエンドポイントを立てる場合は、Cache-Controlの生成ロジックをレビュー対象に入れておくべきところです。

DoH・DoT・DoQの違い｜ポート番号と可視性で分かれる運用の勘所

暗号化DNSはDoHだけではありません。選択肢は3つあり、差は暗号化の強さではなく「ネットワーク側から見分けられるかどうか」に出ます。

443番と853番の差｜ネットワーク側から見分けられるかどうか

DoTはRFC 7858（2016年5月）で定義され、TCPの853番という専用ポートを使います。DoQはRFC 9250「DNS over Dedicated QUIC Connections」（2022年5月）で、UDPの853番とALPN識別子 doq を用いる。どちらも専用ポートなので、ファイアウォール側で「暗号化DNSが出ている」と識別でき、遮断も許可も設計に組み込めます。

DoHは443番のHTTPSに紛れます。これは利点であり、同時に管理上の難点でもある。検閲や強制的なDNS書き換えを回避したい立場では強みになり、社内から出ていく通信を統制したい立場では見えない穴になります。どちらの立場で設計しているのかを最初に決めてください。

DoQ（RFC 9250）とDoH3｜QUICの上で名前解決を運ぶ選択肢

QUICを土台にする選択肢が2つある点は混同されがちです。DoQはQUICストリーム上にDNSメッセージを直接載せる方式で、HTTPを挟みません。対してDoH3は、DoHをHTTP/3の上で動かす形。前者は新しいプロトコル、後者は既存のDoHのトランスポート差し替えです。

いずれもQUICが解決した接続確立の往復とヘッドオブラインブロッキングの恩恵を受け、初回問い合わせの待ち時間が縮みます。モバイル回線のように経路が切り替わる環境では、コネクションIDによる継続性も効いてくる。ただし対応するリゾルバとクライアントの組み合わせはまだ限られるため、2026年8月時点では基本線をDoHに置き、QUIC系は測って効果が出た場合の上積みと考えるのが現実的です。

DoHで隠せる範囲と隠せない範囲｜SNIとECHまで含めた可視性

ここを曖昧にしたまま導入すると、後から必ず説明を求められます。

DNSを暗号化してもアクセス先が漏れる経路とECHで塞げる範囲

DoHが隠すのは、端末とリゾルバの間を流れるドメイン名です。接続先の宛先IPアドレスは、経路上のどこからでも見えます。さらにTLSハンドシェイクの冒頭で送られるSNIには、接続先のホスト名が平文で載る。つまりDoHだけでは、どのサイトへ行ったかは実質的に追跡できます。

この穴を塞ぐ提案がECH（Encrypted Client Hello）で、ClientHelloの一部を暗号化してSNIを隠します。ただし成立にはサーバ側の対応と鍵配布用のHTTPSレコードが要り、2026年8月時点でIETFの標準化作業が続く段階。順序としてはDoHが先で、SNIの秘匿は次の段になります。

DNSSECとの役割分担｜改ざん検知と経路の秘匿は別々の仕組み

DoHとDNSSECは、しばしば取り違えられます。守る対象が違うと考えるのが正確です。DNSSECが担う署名検証と導入手順は、応答が権威サーバの意図どおりかを確かめる仕組みで、経路を暗号化するわけではありません。署名付きの応答も平文で流れます。

逆にDoHは経路を包みますが、リゾルバが返した答えが正しいかは検証しない。リゾルバ自身が嘘をつく可能性は残ります。改ざん検知はDNSSEC、盗み見の防止はDoH。両方が要る場面では、DNSSEC検証を行うリゾルバに対してDoHで接続する構成になります。

クライアント側の設定手順｜ブラウザとWindowsでのDoH有効化

設定の入り口は2系統あります。ブラウザが自前で行う場合と、OSのDNSクライアントが行う場合です。挙動が異なるため、切り分けて確認してください。

ブラウザのセキュアDNS｜ChromeとFirefoxで挙動が変わる点

Chromeは設定のプライバシーとセキュリティから「セキュアDNSを使用する」を有効にでき、既定では現在のDNSサーバがDoH対応と分かっている場合にだけ自動で切り替わる動作を取ります。Firefoxは同じ画面にDNS over HTTPSの項目があり、既定のリゾルバとフォールバックの可否を明示的に選べます。

この差が現場で問題になるのは、ブラウザだけがDoHを使い、OSは平文DNSを使う状態が生まれるためです。社内のフィルタリングをOS側のDNSで実装していると、ブラウザからのアクセスだけ素通りする。ブラウザ側の設定を管理ポリシーで固定できるかを、導入前に確かめておくべきところです。

WindowsのDoHクライアント｜必須・許可・禁止の3つの設定値

Windows Server 2022以降、OSのDNSクライアントがDoHに対応しました。設定の入り口はネットワーク設定の「優先DNS暗号化」で、暗号化のみ、暗号化を推奨するが非暗号化も許可、非暗号化のみ、の3択です。グループポリシーからは「DoHを許可」「DoHを禁止」「DoHが必要」として同じ制御ができます。

選べるのは、指定したDNSサーバが既知のDoHサーバ一覧に載っている場合だけ。既定の一覧はCloudflare・Google・Quad9の3社ぶんで、自社のDoHエンドポイントを使うなら一覧へ追加します。

Get-DnsClientDohServerAddress

Add-DnsClientDohServerAddress -ServerAddress '203.0.113.10' `
  -DohTemplate 'https://doh.example.jp/dns-query' `
  -AllowFallbackToUdp $False -AutoUpgrade $True

注意点がひとつ。Windows Server の DNS Server サービス自体はDoHクエリを受け付けません。Active Directory は名前解決に強く依存するため、ドメイン参加端末に対してDoHを必須化する設定は避けるよう案内されています。この区間の保護が要るなら、IPsecの接続セキュリティ規則で別に手当てする筋になります。

設定が実際に効いているかを確かめる手順｜コマンドとパケットで確認

有効化したつもりで平文に戻っている、という取り違えは珍しくありません。確認は3段構えが手堅い。まず確認するのは、コマンドでDoH経由の解決が成立するかどうかです。BIND 9のdigには +https があり、指定するとポートの既定値が443になります。GETとPOSTを分けて試す +https-get と +https-post も使えます。

dig +https @1.1.1.1 example.jp A

dig +https-get @1.1.1.1 example.jp A

次にパケットを見ます。端末のNICでUDP 53番へのパケットが残っていないかを確認し、443番へのTLSセッションだけになっていれば期待どおり。最後にフォールバックの挙動を試します。DoHエンドポイントを意図的に到達不能にして、名前解決が失敗するのか平文に落ちるのかを実測してください。ここが「許可」設定のままだと、障害時に静かに平文へ戻ります。

リゾルバの自動発見｜DDR（RFC 9462）とDNR（RFC 9463）の役割

RFC 8484が事前設定を前提にしたことで、運用側には「端末ごとにテンプレートを配る」という手間が残りました。これを埋める仕様が後から追加されています。

DDRが解決する問題｜暗号化リゾルバを自動で見つけ出す仕組み

DDRはRFC 9462「Discovery of Designated Resolvers」（2023年11月・Proposed Standard）です。平文リゾルバのIPアドレスしか分かっていない状態から、そのリゾルバが指定する暗号化版へ移る道筋を定めています。動作はSVCBレコードの問い合わせで、特殊用途ドメイン名 _dns.resolver.arpa に対して引くと、ホスト名・ポート・対応プロトコルが返る形。

移行にあたっての検証方法も2種類あります。検証済み発見では、返されたTLS証明書のSubjectAltNameに元のリゾルバのIPアドレスが含まれることを確かめる。プライベートIPアドレスを使う社内環境向けには、同一IPアドレスであることを条件とする機会的発見が用意されています。

DNRとネットワーク提供の設定｜DHCPやRAで配る方式との違い

併走する仕様がRFC 9463で、DHCPオプションとIPv6のルータ広告で暗号化リゾルバの情報を配ります。DDRが「端末がリゾルバへ聞きに行く」方式なのに対し、こちらは「ネットワークが端末へ教える」方式。社内ネットワークで統制を効かせたい場合は、DNR側のほうが素直に組めます。

どちらを採るにせよ、設計上の勘所は同じです。端末が勝手に外部のDoHリゾルバへ向かう前に、社内が指定するリゾルバを先に掴ませる。この順序を作れるかどうかが、統制の成否を分けます。

社内ネットワークでDoHが壊すもの｜内部名前解決とフィルタの設計

導入で揉めるのはたいていこの章の内容です。技術的な失敗ではなく、経路が変わったことによる副作用として現れます。

スプリットDNSが壊れる経路｜社内名の解決が外部へ飛ぶ仕組み

社内向けと社外向けで同じドメイン名に別の答えを返す構成では、端末が社内リゾルバを見ていることが前提になります。内部名前解決とプライベートホストゾーンの設計を採っている環境で端末がDoHで外部リゾルバへ向かえば、社内向けのAレコードは返りません。結果は、社内システムだけ突然つながらないという症状です。

Windowsには名前解決ポリシーテーブル（NRPT）があり、特定の名前空間へのクエリを指定のDNSサーバへ向けられます。社内ドメインだけ社内リゾルバへ固定し、それ以外をDoHへ流す設計が現実解になる。権威DNS側のルーティング設計と合わせて、どの名前をどちらの経路で解くのかを一覧に落としてから作業に入ってください。コンテナ基盤ではクラスタ内リゾルバのCorefile設計が同じ役目を担うため、こちらの転送先設定も点検の対象です。

canaryドメインでの無効化｜効く範囲と当てにできない理由

ブラウザの自動有効化を止める仕掛けとして、canaryドメインという慣行があります。特定の名前を社内DNSでNXDOMAINとして返すと、対応するブラウザがDoHの自動切り替えを見送る、という動作です。導入コストは低く、暫定の抑止としては働きます。

ただし恒久策には向きません。利用者が手動でDoHを有効にした場合には効かず、対応するかどうかもブラウザの実装次第。統制が要件なら、管理ポリシーでの固定とネットワーク側での制御を組み合わせ、canaryドメインは補助と位置づけてください。

自前のDoHリゾルバを立てる選択肢｜構成例と運用で増える負担

外部のパブリックリゾルバへ社内の問い合わせを預けたくない場合、DoHエンドポイントを自前で持つ選択肢があります。構成は難しくありません。既存のキャッシュDNSの前段に、HTTPSを終端してDNSメッセージへ変換するプロキシを置く形が基本です。

変換部分は既存の実装で足ります。443番でTLSを終端し、application/dns-message を受けて背後の53番へ橋渡しする。証明書は通常のWebサーバと同じ運用に載せられます。

負担が増えるのは運用側です。証明書の更新が止まれば名前解決そのものが止まり、影響範囲はWebサイトの停止よりはるかに広い。可用性も、DNSと同じ水準で冗長化する必要があります。加えて、先に触れたHTTPキャッシュとTTLの整合、アクセスログにドメイン名が残ることによる保管期間の設計も要る。パブリックリゾルバを使わない理由が明確な案件に限って選ぶ構成だと考えてください。

受託開発での判断基準｜DoHを前提にする案件と見送る案件の線引き

ここまでを踏まえて、採否の条件を言い切ります。

DoHを前提に設計してよい案件｜公衆網や社外の端末が絡む構成

採用してよいのは、端末が信頼できない経路に出る前提の案件です。営業端末やリモートワーク端末、店舗や現場に置く機器、来訪者向けのネットワーク。これらは経路上の第三者を排除できないため、DoHで得る秘匿と改ざん耐性が実利になります。社内システムを参照しない、あるいはVPN経由でのみ参照する構成なら、スプリットDNSの副作用も出ません。

クラウド上のワークロードで採る場合は、VPC内のリゾルバをDoH対応にするより、通信経路そのものを閉じるほうが素直な場面が多い。どちらが要件に合うかは、既存構成を見ないと決められません。名前解決とネットワーク境界の設計をまとめて委ねたい場合は、クラウドのインフラ構築支援から現行構成の前提を確認するところから相談してください。

DoHを見送るべき場面｜社内の名前解決とログ要件を優先する判断

見送りが妥当なのは3つの場合です。ひとつは Active Directory に参加した端末群。Windows Server の DNS Server がDoHを受けない以上、必須化は名前解決の失敗に直結します。ふたつめは、DNSクエリのログを監査要件として取得している環境。端末が外部リゾルバへ直接向かうと、その記録が手元から消えます。

3つめは、DNSベースのフィルタリングを統制の主軸に据えている環境です。DoHは443番に紛れるため、既存のポート単位の制御では止まりません。この場合は、DoHを止めるのではなく社内のDoHリゾルバへ集約し、そこでフィルタリングを行う形へ組み替えるのが筋です。止める設計と集約する設計、どちらの工数が現実的かを見積もってから決めてください。

よくある質問

DoHを有効にすると通信内容がすべて秘匿されますか？

秘匿されるのは、端末からリゾルバへ送るドメイン名だけです。名前解決の後に接続する宛先IPアドレスは経路上に残り、TLSハンドシェイクのSNIにもホスト名が平文で載ります。どのサイトへアクセスしたかは依然として推測できるため、通信全体の秘匿とは切り分けて説明してください。

DoHとDoTはどちらを選ぶべきですか？

ネットワーク側で暗号化DNSを識別・制御したいならDoT、経路上の干渉を避けたいならDoHです。DoTは853番という専用ポートを使うためファイアウォールで扱いやすく、DoHは443番に紛れるため統制が効きにくい。社内端末の統制が要件ならDoT、社外に出る端末の保護が要件ならDoHが噛み合います。

DoHを社内で無効化するにはどうすればよいですか？

WindowsのグループポリシーでDoHを禁止に設定し、ブラウザ側も管理ポリシーでセキュアDNSを無効に固定します。canaryドメインを社内DNSでNXDOMAINとして返す方法は自動有効化の抑止には働きますが、利用者の手動設定には効きません。恒久的な統制には、ポリシーによる固定を主とし、canaryは補助として組み合わせてください。

DoHにするとDNSの応答は遅くなりますか？

初回は接続確立の分だけ遅くなり、以降は接続を使い回すため差が縮みます。HTTP/2以降の多重化により、複数の問い合わせを1本の接続へまとめられる点も効いてきます。体感差が問題になる場合は、キャッシュの有効期間とリゾルバまでの物理距離のほうが支配的なので、そちらを先に測ってください。

DNSSECを入れていればDoHは不要ではありませんか？

役割が違うため代替にはなりません。DNSSECは応答が改ざんされていないかを署名で検証する仕組みで、クエリの中身は平文のまま流れます。DoHは経路を暗号化しますが、リゾルバが返す答えの正しさは検証しない。両方が要る要件では、DNSSEC検証を行うリゾルバへDoHで接続する構成になります。

関連記事

• 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法を実装者向けに解説：DoHの前提となるDNSの基礎
• DNSSECとは？DNSの安全性を守る仕組みと役割・導入手順をわかりやすく解説：改ざん検知を担う別系統の仕組み
• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説：DoHが土台にする暗号化の中身
• QUIC（通信プロトコル）とは？HTTP/3を支える仕組みとTCPとの違いを実装視点で解説：DoQとDoH3を支えるトランスポート
• プライベートDNSとは？内部名前解決の仕組み・Route 53プライベートホストゾーン・設計を実装者向けに解説：社内解決を壊さない設計
• Amazon Route 53とは？DNS・ドメイン登録・ルーティング設計を実装者目線で解説：権威DNS側のルーティング
• CoreDNSとは？Kubernetesの名前解決の仕組みとCorefile設計を解説：クラスタ内リゾルバの転送設定