Windows 10 22H2でDNS over HTTPS(DoH)を有効化できない理由｜netsh dns add encryptionが使えない時の対処法

Windows 10 Pro 22H2でDNS over HTTPS（DoH／暗号化DNS）をOS標準機能として有効化しようとしても、設定画面に「DNSの暗号化」が出てこない・netsh dns add encryptionが「見つからない」といった壁に当たることがあります。これは不具合というより“対応していない版を使っている”ことが原因です。この記事では、混乱の理由を整理しつつ、Windows 10で現実的に暗号化DNSを使う代替策と、失敗しない確認ポイントをまとめます。

Windows 10 Pro 22H2で「DNSの暗号化」が出ない／netshコマンドが無いのは仕様

まず結論から言うと、Windows 10 Pro 22H2（一般提供の製品版）では、Microsoftの一部ドキュメントやブログに出てくるような「DNS 暗号化」ドロップダウン（Preferred DNS encryption）や、netsh dns add encryption／netsh dns show encryptionのような暗号化DNS向けコマンドが“最初から用意されていない”ケースがあります。
そのため、次のエラーは環境破損ではなく「そのOSビルドに機能が無い」ことを示している可能性が高いです。

The following command was not found: dns add encryption.

実際、Microsoft Q&Aでも「Windows 10 Pro 22H2の主流ビルドではDoHのGUIやnetshコマンドがサポートされておらず、Windows 11（21H2以降）や一部Insiderビルドが対象」という趣旨の回答が示されています。

「2022年はInsiderだけ」だったのに、なぜ今もWindows 10でできないのか

混乱の大きな原因は、検索で当たりやすいMicrosoftの技術ブログが「Windows Insider向けの機能紹介」になっている点です。Insider向けにはDoHのUIや、DoHサーバー定義を追加するためのnetsh dns add encryptionなどが紹介されていました。

一方で、Windowsのコアネットワーキングチームの別記事では「DoHのクライアントサポートはWindows 11とWindows Server 2022で出荷された」と明記されており、Windows 10の製品版に最終的に同等機能が入らなかった背景が読み取れます。

さらに、Windows 10は“最終バージョンが22H2”であることがMicrosoft Learnのリリース情報でも示されており、機能追加の期待値は現実的に下がります（品質更新はあっても、新機能が追加される流れではありません）。

そもそもDoH（DNS over HTTPS）で何が変わるのか

DoHは、DNS問い合わせ（例：example.comはどのIP？）をHTTPSで包んで送る仕組みです。従来の平文DNS（主にUDP/53）と違い、ネットワーク上でDNSの中身を覗かれたり改ざんされたりするリスクを下げられます。DoHは通常のHTTPSと同じ443番ポートを使うため、通信がHTTPSトラフィックに紛れやすいという特徴もあります。

ただし、DoHは「DNSだけ」を暗号化する技術です。Webアクセスそのもの（接続先IP、HTTPS通信量、接続タイミングなど）を完全に隠すものではありません。VPNやTorと同列に考えると期待外れになるので、目的（盗聴対策／改ざん対策／プライバシー強化）を明確にするのが重要です。

症状チェック：Windows 10 22H2でよくある“できない”状態

確認ポイント	期待	Windows 10 22H2（製品版）で起きがち
設定アプリに「DNSの暗号化／Preferred DNS encryption」がある	存在する	項目が出ない（DNS欄はあるが暗号化の選択が無い）
`netsh dns add encryption`が通る	コマンドが実行できる	「command was not found」になる
`netsh dns show encryption`で一覧が出る	DoH/DoT定義が表示される	同様に「command was not found」になる

この状態は、SFCやDISMで「修復」して直るタイプの問題ではありません。
“機能が入っていないOS（または入っていないエディション／ビルド）”を使っていることが根本原因です。

Windows 10でDoHを使う現実解は「別レイヤーで実現する」こと

Windows 10のOS標準機能としてDoHを有効にできない場合でも、暗号化DNSをあきらめる必要はありません。実務的には次の3ルートが現実解です。

方法	守れる範囲	導入難易度	こんな人におすすめ
ブラウザのDoHを有効化	ブラウザのDNSのみ	低	Web閲覧中心／まず手軽にやりたい
ローカルDoHプロキシ（DNSクライアント）を導入	PC全体（システムDNS）	中〜高	ゲーム・メール等も含めて暗号化DNSにしたい
ルーター／ゲートウェイ側でDoH/DoT	家庭内ネットワーク全体	中	端末が複数ある／家族・社内で統一したい

方法：ブラウザ側でDNS over HTTPS（DoH）を有効化する

「とにかく今日から効果が欲しい」なら、まずブラウザDoHが最短距離です。OSが非対応でも、Chrome／Edge／Firefoxはブラウザ内でDoHを使えます（＝ブラウザがDNS問い合わせを自前でDoHに置き換えるイメージ）。

Chrome / Edgeの設定ポイント

設定画面の「プライバシーとセキュリティ」配下にある「セキュリティ」項目を開く
「安全なDNSを使用する（Use secure DNS）」を有効化
プロバイダーを選択（例：Cloudflare、Google など）またはカスタムURLを指定

注意：会社PCやVPN環境では、ポリシーでDoHが制限されていることがあります。まずはブラウザだけで効くかを確認し、ダメなら次の「ローカルプロキシ方式」を検討するのが安全です。

Firefoxの設定ポイント

設定 → ネットワーク設定（接続設定）を開く
「DNS over HTTPSを有効にする」にチェック
プロバイダーを選ぶ（またはカスタムURL）

ブラウザDoHの弱点は「ブラウザ以外のアプリは従来のDNSのまま」になりやすい点です。Web閲覧だけ守れれば十分ならこれでOKですが、OS全体で暗号化DNSに寄せたい場合は次の方法が本命です。

方法：Windows 10でも“PC全体”を暗号化DNSにする（ローカルDoHプロキシ）

Windows 10でOS標準DoHが無い場合、よく使われるのが「ローカルでDNSプロキシ（スタブリゾルバ）を動かす」方式です。Windowsはローカル（例：127.0.0.1）へ通常DNSで投げ、ローカルプロキシが上流へDoH/DoTで中継します。これにより、OS全体の名前解決を暗号化された経路へ寄せられます。

代表的な選択肢（Windows 10で導入されやすいもの）

ツール	対応プロトコル	特徴	向いている人
Cloudflare WARP（1.1.1.1モード）	暗号化DNS（DoH/DoT相当）	1.1.1.1宛のDNSだけ暗号化。UIで切替しやすい	手軽さ最優先／CloudflareでOK
Cloudflare WARP（WARPモード）	トンネル（WireGuard系）＋DNS暗号化	通信全体を暗号化してWARPへ送る。DNSも含まれる	“DNSだけ”ではなく、もう一段守りたい
dnscrypt-proxy	DoH / DNSCrypt / ODoH など	高機能なDNSプロキシ。フィルタや負荷分散なども可能	細かく制御したい／検証しながら固めたい
Stubby	DoT	DoT特化のローカルスタブ。DoH目的なら優先度は低い	DoHでなくDoTでも良い／シンプルにDoTしたい

Cloudflare WARPは「WARP」と「1.1.1.1」の2モードがあり、1.1.1.1モードではDNSトラフィックだけを暗号化して1.1.1.1へ送る設計です。まずは“DNSだけ暗号化したい”場合に扱いやすいです。

dnscrypt-proxyは、DoHを含む複数の暗号化DNSプロトコルを扱える柔軟なDNSプロキシとして知られています。プロファイルやフィルタリングなども可能なため、家庭内でPi-holeと組み合わせたい人にもよく使われます。

Stubbyは“DNS-over-TLS（DoT）”のローカルスタブリゾルバとして紹介されることが多く、DoHを目的に名前だけで選ぶとミスマッチになりがちです。DoTで良いなら候補になります。

ローカルプロキシ方式の導入でつまずきやすいポイント

Windows側のDNS設定はIPしか持てない
多くのアプリは「127.0.0.1:53」で待ち受ける前提になります。プロキシが別ポートの場合、別途フォワーダ構成が必要になり難易度が上がります。
起動順で“DNSが死ぬ”
DNSを127.0.0.1に向けたのにプロキシが起動していないと、名前解決が止まります。サービス化／自動起動の確認が必須です。
VPNやセキュリティ製品がDNSを上書きする
VPN側が独自DNSを強制する場合、プロキシ設定が無効化されることがあります。

プロバイダー	主なDNS（IPv4）	DoHエンドポイント例	特徴
Cloudflare（1.1.1.1）	1.1.1.1 / 1.0.0.1	https://cloudflare-dns.com/dns-query	高速・普及率が高い。DoHの説明と仕様が明確
Google Public DNS	8.8.8.8 / 8.8.4.4	https://dns.google/dns-query	RFC 8484対応のDoHを公式に案内
Quad9	9.9.9.9 / 149.112.112.112	https://dns.quad9.net/dns-query	マルウェアブロック系の系統が選べる

「DoHが効いているか」を確認する実践的な方法

確認の考え方

暗号化DNSの確認でありがちな落とし穴は、「DNSサーバーがどれか（=どこへ問い合わせたか）」と「暗号化されているか（=どう運ばれたか）」を混同することです。
DNSリークテスト系のサイトは“どのDNSリゾルバに見えているか”の確認には便利ですが、あなたのPC〜リゾルバ間が常に暗号化されているかの断定には不十分な場合があります。

Quad9を使っている場合：プロトコル判定用のTXTを引く

Quad9には、受信したプロトコルを返すテスト用ドメインが用意されています。PowerShellで次を実行し、結果にhttpsやtlsが含まれるかを確認します（環境によって返り値の形式は異なります）。

Resolve-DnsName -Type txt proto.on.quad9.net.

パケットで確認する（上級）

Wireshark等でudp.port == 53を見て、外向きに平文DNSが出ていないか確認する
ローカルプロキシ方式の場合、ローカル（127.0.0.1）への53番通信は見えても正常（Windows→ローカルプロキシ間）
外側へはDoHなら443番（HTTPS）で出ていくのが期待値になります。

なぜWindowsは“IPとDoHテンプレートの紐づけ”を要求するのか

Insider向けブログでは、Windowsが「このDNSサーバーIPはDoH対応で、テンプレートはこれ」という対応表を持つ設計が説明されています。ドメイン名だけでDoH先を指定できるようにすると、最初の名前解決（ブートストラップ）で平文DNSが発生し、経路上の攻撃者に差し替えられる余地が残るため、Windows側は強い保証を優先してIPとテンプレートの対応を前提にしています。

この思想があるため、「設定画面に出ているDNSなのに暗号化の選択肢がグレーのまま」という現象も起こりえます（＝OSが“DoH対応として認識しているサーバー”に該当しない）。Windows 10の話題で混乱しやすい部分ですが、Windows 11/Server側でも“対応サーバーの定義”という考え方は重要です。

どうしてもOS標準のDoH（netsh/設定UI）を使いたい場合

OS標準の「DNSの暗号化」UIやnetshの暗号化DNSコマンドで管理したい場合、現実的な選択肢はWindows 11へ移行することです。Microsoftのネットワーキングブログでも、DoHクライアントサポートはWindows 11で出荷されたとされています。

まとめ：Windows 10の“できない”は不具合ではなく前提条件の違い

Windows 10 Pro 22H2（製品版）で「DNSの暗号化」項目が出ない／netsh dns add encryptionが見つからないのは、OS側に機能が無いことが原因になりやすい
Microsoftの一部手順はInsider向けで、Windows 10製品版と画面・コマンドが一致しないことがある
Windows 10で暗号化DNSを使うなら、ブラウザDoH（手軽）か、ローカルDoHプロキシ（PC全体）で実現するのが現実的
プロバイダーやクライアントによっては仕様変更もある（例：Quad9のDoH HTTP/1.1終了告知）ため、長期運用なら“クライアント側の対応状況”も見る

Windows 10で「OSレベルでDoHができない」状況でも、目的が“DNSの盗聴・改ざん耐性を上げたい”であれば、代替手段で十分に実用レベルまで持っていけます。まずはブラウザDoHで効果を体感し、次にローカルプロキシで全体を暗号化する、という順番が失敗しにくい進め方です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。