DNS over HTTPS

DNS over HTTPS（DoH）は、リモートのDNS解決をHTTPSプロトコルを用いて実行するためのプロトコルである。

**概要**
この手法の目的は、プライバシーとセキュリティを向上させ、盗聴を防いだりDNSデータの中間者攻撃による操作から保護することである。そのために、DoHクライアントとDoHベースのDNSリゾルバ間のデータをHTTPSプロトコルを使用して暗号化する。
ただし、この技術(DoH)やDoT(DNS over TLS)による暗号化自体は、label=が言うように盗聴、検閲やプライバシーの面で政府に対抗しうる保護を提供するものではなく、データを難読化するものである。端末（あるいはスタブリゾルバ、以下同）からDNSリゾルバまでの間の盗聴や中間者攻撃からの保護には効果がある。
ある端末からのDNSクエリ全体のプライバシー確保は、DNSフルリゾルバのポリシーおよび権威サーバとの通信形態に依存する。
DoH/DoTとDNSSECは競合しない。DNSSECはリゾルバや権威サーバ間のドメイン登録情報のやり取りに電子署名を付加して完全性を担保するものであり、当該登録情報のやり取り自体は平文である。EDNS Client Subnet（英語版）ではロードバランス目的のために、フルリゾルバは端末からのクエリのIPアドレスのサブネットを権威サーバに渡す場合があり、その場合、フルリゾルバと権威サーバの間との間で、端末のサブネットとクエリドメインの組み合わせ情報が、平文で通信される。フルリゾルバと権威サーバ間の通信も暗号化するものはDNSCurveによって実装される。

**技術**
DoHは、8484（October 2018）としてIETFが公開した提案段階 (Proposed Standard; 2021年1月時点)の標準である。
DoHでは、HTTP/2とHTTPSを使用し、既存のUDPレスポンスではwire formatのDNS responseデータをサポートし、HTTPSペイロードではMIMEタイプのapplication/dns-messageを使用する。HTTP/2を使用した場合、サーバーはlabel=を利用することで、クライアントに通知しておくと役に立つと予想されるデータを事前に送ることが可能になる。
前述のようにDoHは策定中の標準であるため、様々な企業がそれをもとに実験を行っており、IETFは、まだどのような実装が最善であるかは最終的に決定していない。IETFはDoHの最適なデプロイ方法について様々なアプローチを評価中であり、 Applications Doing DNS (ADD)というワーキンググループを立ち上げて必要な作業とコンセンサスの構築に取り組んでいる。その他に、 Encrypted DNS Deployment Initiativeという企業によるワーキンググループも立ち上がっており、その目的は「インターネットの重要なネームスペースと名前解決サービスの高性能、回復性、安定性、セキュリティを確保し、DNSに依存するセキュリティ保護やペアレントコントロールなどのサービスを損なわないように提供できるように、DNS暗号化技術を定義・適用すること」であると述べられている。
DoHを適切にデプロイする方法には多くの課題があり、インターネットコミュニティにより解決が試みられている。課題には以下のものが含まれるが、これがすべてではない。- ペアレンタル・コントロールとコンテンツ・フィルタ
*DNSが企業内に分散される- CDNによるローカライゼーション- 5Gネットワークとの相互運用性

**Oblivious DNS-over-HTTPS**
Oblivious DNS-over-HTTPSは、すべてのリクエストをプロキシ経由で行うことでクライアントのアドレスを削除することにより、どのクライアントがどのようなドメイン名をリクエストしたのかをDoHのresolverから隠蔽しようとするDoHの拡張である。すべての接続はレイヤー内で暗号化されるため、プロキシはクエリの内容とレスポンスを知ることができず、クライアントのアドレスもわからないようになっている。

**デプロイのシナリオ**
DoHはDNSリゾルバによる再帰的なDNS解決に使用される。リゾルバ（DoHクライアント）はクエリエンドポイントをホストするDoHサーバーへアクセスできる必要がある。
、DoHにはオペレーティングシステム (OS) のネイティブサポートが少ないため、ユーザーは追加のソフトウェアのインストールが必要となる場合がある。次の3つの使用方法が一般的である。- アプリケーション内に含まれるDoHの実装を使用する。
**ビルトインのDoH実装が行われているブラウザでは、OSのDNS機能をバイパスむしろ名前解決はネットワークアプリケーションの主要な動機の1つであり、OSはその手段の1つをAPIとして提供しているに過ぎない。この場合は、アプリケーションが自発的にDoHに接続するものであり、OS内部で何らかのバイパス機構を組み入れる訳ではない。してクエリを実行することができる。欠点は、設定ミスやその他により、アプリケーションがユーザーにDoHクエリをスキップしたかどうかを通知しない場合があることである。2020、Mozilla FirefoxやGoogle Chrome等で個別の名前解決にDoHを利用したかどうか簡便に知る手段がない。- ローカルネットワークのネームサーバーにDoHプロキシをインストールする。
**クライアントシステムは従来のDNSここでは、OSによる名前解決という意味である。OSによって従来のDNSクエリ（ポート53/DNS）、あるいはOSが対応していればポート853/DoTによる。さらにここでは、そのOSによる名前解決のリゾルバにローカルネットワークのネームサーバーを指定する前提である。を使用してローカルネットワークのネームサーバーにクエリを送り、ネームサーバーは、レスポンスに必要な情報をインターネット上のDoHサーバーへDoHを使用してアクセスし取得する。この手法はエンドユーザーに対して透過的である。欠点は、サーバ構築管理が容易でないこと、ブロードバンドルータ等への実装が普及しない事などである。- ローカルシステムにDoHプロキシをインストールする。
**OSをローカルで動作するDoHプロキシにクエリを送るように設定する。1つ前の手法と比べると、DoHを使用したいすべてのシステムにインストールする必要があり、大規模な環境では多くの作業が必要になる可能性がある。- DoHリゾルバプラグインをOSにインストールする。
**前者と同様に、DoHリゾルバプラグインをOSに組み込んで設定する。OS側がそのようなプラグインのインストールに対応している必要がある。DoHを使用したいすべてのシステムにインストールする必要があるのも前者と同様。
これらすべてのシナリオにおいて、DoHクライアントは権威ネームサーバーに対していかなるクエリも直接行わない。その代わりに、DoHサーバーは従来のポートを使用したクエリを発行し、最終的に権威サーバーに到達する。そのため、DoHはエンドツーエンド暗号化プロトコルではなく、ホップ間の暗号化を行うもので、DNS over TLSが一貫して使用された場合に限られる。

**実装**

**OSのサポート**
2019年11月、Microsoftは、Microsoft WindowsでDoHを始めとするencrypted DNSプロトコルをサポートする実装を行う計画を発表し、2021年にWindows 11にDoHのサポートを追加した。
Android 9以降でDoTに対応しているが、DoHには最新バージョン（2020年時点）でも対応していない。このDoT仕様では、DHCP配布その他の既定DNSサーバに対しDoTで接続を試み、失敗すれば従来のDNSクエリにフォールバックするというモードがデフォルトである他に従来のDNSクエリモード、あるいは指定されたDoT対応DNSサーバへのDoTクエリ専用モード（この場合接続できないと名前解決失敗となる）がある。。なお、Android 9ではVPN接続に対してDoTの設定が適用されないバグがあり、これはAndroid 10で修正されている。
少なくともiOS 14、macOS Big Sur以降でDoH/DoTをサポートしている。

**クライアントのサポート**
 AdGuard for Android, AdGuard for iOS and AdGuard Home
*Cloudflare 1.1.1.1 client app for Android and iOS.
*Cloudflare resolver for Linux, MacOS and Windows.- cURL since 7.62.0.- DNSCrypt-proxy — Local DNS → DNS over HTTPS proxy.- DNSP — Versatile DNSProxy. DoH server (C) and client (PHP) implementation.- doh-php-client — PHP Implementation.- Firefox since Version 62 and later — Browser support.- go-doh-proxy — Go DoH Proxy Server.- Intra — Android app by label=Jigsaw.- nss-tls — a DoH-based resolver plugin for glibc.- Technitium DNS Client — C# .NET cross-platform implementation.- NextDNS client apps.- Nebulo - DNS over HTTPS/TLS - for Android.

**提供サービス**
DNS over HTTPS (DoH) サーバーの実装は、いくつかのlabel=パブリックDNSサービスプロバイダから無料で利用できるようになっている。また、多くのパブリックDNSサービスでは、DoHサービスと並行してDoTサービスも提供している。
例えばGoogle Chrome は Version 78からDoH対応しているが、Version 87.0では、Google Public DNS、OpenDNS、Cloundflare、label=、IIJ Public DNSIIJではあくまでも試験的サービスという位置づけである（開始 - 2021年1月現在）。がプリセットドメインとなっている（他のDoHサービスも利用できる）。
冒頭に述べたとおり、ある端末からのDNSクエリ全体のプライバシー確保は、DNSフルリゾルバを提供するパブリックDNSサービスのプライバシーポリシー等に大きく依存する。

**諸問題ほか**

**サポート面**
現状（2020年現在）まで、DoHの有効化設定にはOSやクライアントでユーザが積極的にインストールや設定をする必要がありただし、Android 9以降では、DoTが自動設定されている。また、Google ChromeでもセキュアDNSがデフォルトONとなっている。ただし、これらの設定で具体的にどのDoH/DoTサーバに接続を試み、または従来のDNSクエリにフォールバックするのかは明らかになっていない。、DHCP/DHCPv6などによる端末側自動設定などの仕組みは標準化されていない。

**何が改善されうるのか**
セキュリティの向上に加えて、性能の向上もDNS over HTTPSの目的の1つであると言われる。しかし、これはDoHに本質的なものではなく、むしろプロトコル・オーバヘッド自体は従来のDNSクエリよりも暗号化やhttpsセッション管理の分、悪化しうる。性能の向上というのは、現状の選択肢の上ではサービス利用上の前提となるPublic recursive name serverの利用に伴うものが主張されている。ISPが提供するDNSリゾルバは（貧弱なものでは）75パーセンタイルで181ミリ秒掛かっているという調査があり、遅いため、1つのウェブページで10以上の名前解決が必要とされる今日では、ユーザのウェブ体験におけるレスポンスが悪化する場合があり、問題となっている。パブリックDNSサーバーではそのような点において、ISP提供のDNSサーバのそれと比較した速度・レスポンスの改善に訴求点を置いていた。
しかし、中間者攻撃などによるDNSスプーフィングやドメイン名ハイジャック等の諸攻撃の脅威が現実味を帯びた2000年代後半以降は、レスポンス性能は重要な訴求では無くなった。例えば、ISPのDNSサービスに直接、従来のDNSクエリを投げる場合と比べて、Public recursive name serverへ直接、従来のDNSクエリを投げる場合には、ISP事業者外のネットワークを平文で通過するため、そのクエリ自体に中間者攻撃などに遭うリスクが増加する。よって、何らかの理由によりパブリックDNSサーバーを利用するのであれば、DoH/DoTを使用した方がセキュリティ上は望ましいと考えられるなお、DoH/DoTへの接続設定に関し、ホスト名またはホスト名を含むURLが指定される場合が多いが、その場合、DoH/DoTサーバーへの接続にはOS経由の名前解決が必須となる。そのため、設定や環境によっては、DoH/DoTサーバーの名前解決に対する中間者攻撃のリスクが残ったり、それ自体にDNSブロッキングが掛かる場合がある（従来のDNSクエリ方式では、DNSサーバのIPアドレスを直接設定する）。。
ISPのDNSサービスの品質が相当悪くない限り（そしてそれは国やISP事業者にもよるが少ない）、ネットワークホップ数上、近くにあるISPのDNSサーバーの方が。概ねホップ数の多いパブリックDNSサーバーよりも有利である事が多い。これは、そのlabel=パブリックDNSサービスプロバイダのロードバランス方針およびユーザと実リゾルバ間のネットワーク上の距離に依存する（なお、ISPのDNSサーバーもロードバランス方針については同じ立場にある）。
公衆Wi-Fiその他ネットワーク層レベルで信頼性の低いものEfn2|他には、宿泊施設/集合住宅等提供/ゲスト借用のWi-Fiアクセスポイント経由、あるいは宿泊施設/集合住宅等提供の有線LAN経由インターネット、さらには十分に保護されていないFTTx(FTTB)その他の共用インターネット施設サービスが想定される。なお、ユーザ個宅まで直接光ケーブルを引き込むFTTH(FTTP)では、光ファイバー経路上は通常暗号化されており、このような問題は無い。を利用するケースなどなお、モバイルネットワーク経由の場合は、通常のモバイル事業者(ISP)であれば、適切に当該ISPのDNSサーバーにクエリするよう設定されるため、この問題は無い。、盗聴やなりすましのリスクが常にある環境においては、従来のDNSクエリ方式では平文でやり取りされるため、中間者攻撃などに遭うリスクが増加する事になる。あるいは、接続先のネットワークでデフォルト提供されるDNSリゾルバに信頼性その他問題がある場合もある。これらの場合もDoH/DoTを使用した方がセキュリティ上は望ましい場合があるなお、DoH/DoTへの接続設定に関し、ホスト名またはホスト名を含むURLが指定される場合が多いが、その場合、DoH/DoTサーバーへの接続にはOS経由の名前解決が必須となる。よって、設定や環境によっては、DoH/DoTサーバーの名前解決に対する中間者攻撃のリスクが残ったり、それ自体にDNSブロッキングが掛かる場合がある（従来のDNSクエリ方式では、DNSサーバのIPアドレスを直接設定する）。。

**ポリシーと批判**
DoHは、IPアドレスやServer Name Indication（SNI）などの、HTTPSリクエストの暗号化されていない部分からまだ取得できる情報だけを暗号化していることから、誤った意味のセキュリティを提供するものであると主張されてきた。
また、現在のウェブブラウザのDoHの実装はサードパーティのDNSプロバイダに依存しているため、DNSの非中央集権的な性質とは逆であり、プライバシーの問題がある。OpenBSDは、FirefoxのビルドでCloudflareのサービスがデフォルトで使われているという理由で、DoHをデフォルトで無効化した。
Google Chromeでは、ユーザーが選んだDNSプロバイダがDoHをサポートしている場合にのみDoHを使用するが、アメリカのISPからは、ユーザーにGoogle Public DNSサービスの使用を強制することになると非難された。

**セキュリティ面**
DoHは、サイバーセキュリティのために実施されているDNSトラフィックの解析や監視から逃れて隠れる手段を提供する。2019年、DDoSワームのGodulaは、command-and-controlサーバーへの接続を隠すためにDoHを利用した。DoHは、コンテンツフィルタリングソフトウェアやエンタープライズのDNSポリシーに対するバイパスとなる可能性が論じられている。

**コンテンツのフィルタリング政策面**
イギリスのISPを代表する業界団体のlabel=とlabel=（ISPA）は、広く使われているFirefoxウェブブラウザを開発しているMozillaとGoogleに対して、DoHのサポートにより、ISPデフォルトの成人向けコンテンツのフィルタリングや裁判所の命令による著作権侵害サイトの強制フィルタリングなどのlabel=プログラムが弱体化してしまう恐れがあると非難した。ISPAは2019年にMozillaに「インターネットの敵（Internet Villain）」賞を（EUのデジタル単一市場における著作権に関する指令とDonald Trumpとともに）与えた。受賞理由は「イギリスのフィルタリングの義務とペアレンタル・コントロールをバイパスするDNS-over-HTTPSの導入により、イギリスのインターネットの安全基準を劣化させた」というものである。MozillaはISPAの主張に対して、DoHはフィルタリングを妨げるものではなく、「ISPの業界団体が、数十年前の古くなったインターネットインフラの改善に対して誤った判断をしていることに驚き、残念に思う」と述べた。この批判に対してISPAは謝罪し、ノミネートを取り下げた。Mozillaはその後、関連するステークホルダーとの十分な議論が行われるまではイギリスではDoHを使用しないようにすると発表したが、「イギリスにも現実のセキュリティ上の恩恵を提供できるはずだ」と述べている。

**プライバシー追跡面**
従来のDNSクエリの場合、DNSリゾルバ側からは、スタブリゾルバ（多くの場合、組織内のルーター）のIPアドレス以外は見えないため、実際のクエリをリクエストした端末やユーザを固有追跡する事は困難であった（IPv6でも、端末側で一時アドレスを利用すれば、ネットワークアドレス以外の追跡は困難である）。
しかしDoH/DoTにおいては、HTTPSによりTLSセッションが維持され続けるため、DNSリゾルバ側から端末単位でクエリの追跡が原理上可能となる。さらにTLSの仕様上、IPアドレス（ネットワーク上の場所）に変化があっても同一のTLSセッションを再開できるため、端末単位の追跡が容易となる。
また、DoH/DoTセッションでクライアント（例えばWebブラウザ）側が渡す user-agent ヘッダその他の情報もユーザ追跡上重要な情報となり得る。さらにDoHセッション毎にcookieの設定も理論上は可能である（実装上は不明）。
以上の問題は、ユーザ側とDNSフルリゾルバ（現状ではサービス利用上選択肢前提となるPublic recursive name server）間の、クエリに関するデータ利用・プライバシーポリシーに完全に依存する。

**関連項目**
 label=- DNS over TLS- DNSCurve- DNSCrypt- DNS

**脚注**

**注釈**

**出典**

**外部リンク**
  DNS Privacy Project: dnsprivacy.org-  DNS over HTTPS Implementations-  A cartoon intro to DNS over HTTPS-  DNS over HTTPS: Ultimate Guide-  DNS-over-HTTPS (DoH) Operational and Privacy Issues