TLS 経由の DNS

DNS over TLS ( DoT ) は、トランスポート層セキュリティ(TLS) プロトコルを介してドメイン ネーム システム(DNS) クエリと応答を暗号化してラップするネットワークセキュリティ プロトコルです。この方法の目的は、中間者攻撃による DNS データの盗聴や操作を防ぐことで、ユーザーのプライバシーとセキュリティを強化することです。DoTの既知のポート番号は 853 です。

DNS over TLS はあらゆる DNS トランザクションに適用できますが、 2016 年 5 月のRFC 7858 で、スタブまたは転送リゾルバと再帰リゾルバ間の使用のために最初に標準化されました。その後の IETF の取り組みでは、再帰サーバーと権威サーバー間の DoT の使用 (「Authoritative DNS over TLS」または「ADoT」) ^[1]と、権威サーバー間の関連実装 (Zone Transfer-over-TLS または「xfr-over-TLS」) が指定されています。^[2]

BINDはバージョン9.17からDoT接続をサポートしています。^[3]以前のバージョンでは、stunnelを介してプロキシすることでDoT機能を提供していました。^[4] Unboundは2023年1月22日からDNS over TLSをサポートしています。^{[5] [6]} Unwindは2023年1月29日からDoTをサポートしています。 ^{[7] [8]} Android PieのDNS over TLSのサポートにより、一部の広告ブロッカーは、 VPNやプロキシサーバーなどの通常使用されるさまざまな回避策よりも、比較的簡単な方法として暗号化されたプロトコルの使用をサポートするようになりました。^{[9] [10] [11] [12]}

Android Pie以降を実行しているAndroidクライアントはDNS over TLSをサポートしており、ISPなどのネットワークインフラストラクチャがサポートしている場合はデフォルトでそれを使用します。^{[13] [14]}

2018年4月、GoogleはAndroid PieにDNS over TLSのサポートが含まれると発表しました。^{[15]これにより、ユーザーはWi-Fiとモバイル接続の両方で電話全体にDNSサーバーを設定できるようになります。これは、これまでは}ルート化されたデバイスでのみ可能だったオプションです。PowerDNSのDNSDistも、バージョン1.3.0でDNS over TLSのサポートを発表しました。^[16]

LinuxおよびWindowsユーザーは、NLnet LabsのスタビーデーモンまたはKnot Resolverを介してクライアントとしてDNS over TLSを使用できます。 ^{[17]または、getdns-utils [18]}をインストールして、getdns_queryツールでDoTを直接使用することもできます。NLnet Labsのunbound DNSリゾルバもDNS over TLSをサポートしています。^[19]

AppleのiOS 14では、 DNS over TLS（およびDNS over HTTPS）のOSレベルのサポートが導入されました。iOSではDoTサーバーの手動設定は許可されておらず、設定変更にはサードパーティのアプリケーションを使用する必要があります。^[20]

systemd-resolvedはLinux専用の実装で、/etc/systemd/resolved.conf設定を編集して有効にすることでDNS over TLSを使用するように設定できますDNSOverTLS。^{[21] [22]}ほとんどの主要なLinuxディストリビューションではsystemdがデフォルトでインストールされています。^{[23] [循環参照]}

DNS over TLSは、 2017年にQuad9によってパブリック再帰リゾルバに初めて実装されました。^{[24] [25]その後、} GoogleやCloudflareなどの他の再帰リゾルバオペレーターもこれに追随し、現在ではほとんどの大規模再帰リゾルバで一般的に利用できる広くサポートされている機能となっています。^{[26] [27] [28] [29] [30] [31] [32] [33] [12]}

DoTは、サイバーセキュリティ目的でのDNSトラフィックの分析と監視を妨げる可能性があります。DoTは、 （暗号化されていない）標準DNSレベルで動作するペアレンタルコントロールを回避するために使用されてきました。DNSクエリを使用してドメインをブロックリストと照合するペアレンタルコントロールルーターであるCircleは、このためデフォルトでDoTをブロックします。^[34]ただし、DoTとDoHの両方のサポートに加えて、フィルタリングとペアレンタルコントロールを提供するDNSプロバイダーがあります。^{[35] [36] [37] [38] [39] [12]}そのシナリオでは、DNSクエリはユーザーのルーターを離れる前ではなく、プロバイダーが受信した後にブロックリストと照合されます。

他の通信と同様に、DNS 要求の暗号化だけではプライバシーは保護されません。第三者の監視からは保護されますが、エンドポイントが (その後復号化された) データをどのように処理するかは保証されません。

DoT クライアントは、必ずしも権威ネーム サーバーに直接クエリを実行するわけではありません。クライアントは、従来の (ポート 53 または 853) クエリを使用して DoT サーバーに依存し、最終的に権威サーバーに到達します。したがって、DoT はエンドツーエンドの暗号化プロトコルではなく、ホップツーホップの暗号化のみであり、DNS over TLS が一貫して使用されている場合にのみ有効です。

DNS over HTTPS (DoH) は、 DNSクエリを暗号化するための同様のプロトコル標準であり、DoT とは暗号化と配信に使用される方法のみが異なります。プライバシーとセキュリティの観点から、2 つのプロトコルのうちどちらが優れているかは議論の余地のある問題ですが、どちらのメリットも特定の使用例によって異なると主張する人もいます。^[40]

DNSCrypt は、DNS トラフィックを認証および暗号化する別のネットワーク プロトコルですが、RFC ( Request for Comments )でインターネット技術タスク フォース(IETF)に提案されたことはありません。

• パブリック再帰ネームサーバー
• HTTPS 経由の DNS
• DNS暗号化
• DNSカーブ

• RFC  7858 – DNS over Transport Layer Security (TLS) の仕様
• RFC  8310 – DNS over TLS および DNS over DTLS の使用プロファイル
• DNS プライバシー プロジェクト: dnsprivacy.org