DNS over HTTPS
DoHは、IPアドレスやServer Name Indication(SNI)などの、HTTPSリクエストの暗号化されていない部分からまだ取得できる情報だけを暗号化していることから、誤った意味のセキュリティを提供するものであると主張されてきた。
また、現在のウェブブラウザのDoHの実装はサードパーティのDNSプロバイダに依存しているため、DNSの非中央集権的な性質とは逆であり、プライバシーの問題がある。OpenBSDは、FirefoxのビルドでCloudflareのサービスがデフォルトで使われているという理由で、DoHをデフォルトで無効化した。
Google Chromeでは、ユーザーが選んだDNSプロバイダがDoHをサポートしている場合にのみDoHを使用するが、アメリカのISPからは、ユーザーにGoogle Public DNSサービスの使用を強制することになると非難された。
DoHは、RFC 8484(October 2018)としてIETFが公開した提案段階 (Proposed Standard; 2021年1月時点)の標準である。
DoHでは、HTTP/2とHTTPSを使用し、既存のUDPレスポンスではwire formatのDNS responseデータをサポートし、HTTPSペイロードではMIMEタイプのapplication/dns-messageを使用する。HTTP/2を使用した場合、サーバーはHTTP/2 server push(英語版)を利用することで、クライアントに通知しておくと役に立つと予想されるデータを事前に送ることが可能になる。
前述のようにDoHは策定中の標準であるため、様々な企業がそれをもとに実験を行っており、IETFは、まだどのような実装が最善であるかは最終的に決定していない。
この手法はエンドユーザーに対して透過的である。欠点は、サーバ構築管理が容易でないこと、ブロードバンドルータ等への実装が普及しない事などである。
ローカルシステムにDoHプロキシをインストールする。 OSをローカルで動作するDoHプロキシにクエリを送るように設定する。1つ前の手法と比べると、DoHを使用したいすべてのシステムにインストールする必要があり、大規模な環境では多くの作業が必要になる可能性がある。
DoHリゾルバプラグインをOSにインストールする。 前者と同様に、DoHリゾルバプラグインをOSに組み込んで設定する。OS側がそのようなプラグインのインストールに対応している必要がある。DoHを使用したいすべてのシステムにインストールする必要があるのも前者と同様。
これらすべてのシナリオにおいて、DoHクライアントは権威ネームサーバーに対していかなるクエリも直接行わない。その代わりに、DoHサーバーは従来のポートを使用したクエリを発行し、最終的に権威サーバーに到達する。そのため、DoHはエンドツーエンド暗号化プロトコルではなく、ホップ間の暗号化を行うもので、DNS over TLSが一貫して使用された場合に限られる。