1. Introduction (はじめに)

今日、ほぼすべてのDNSクエリ [RFC1034] [RFC1035] は暗号化されずに送信されており、ネットワークチャネルへのアクセス権を持つ攻撃者による盗聴に対して脆弱であり、クエリ発行者のプライバシーを低下させます。最近のニュース報道によってこれらの懸念が高まっており、最近のIETFの活動ではDNSのプライバシー考慮事項 [RFC7626] が規定されています。

これまでの取り組みは、DNSセキュリティのいくつかの側面に対処してきましたが、最近まで、DNSクライアントとサーバー間のプライバシーに関する取り組みはほとんどありませんでした。DNS セキュリティ拡張 (DNS Security Extensions, DNSSEC) [RFC4033] は、ゾーンに暗号署名するメカニズムを定義することによってレスポンス完全性 (response integrity) を提供し、エンドユーザー (またはそのファーストホップリゾルバ) が応答が正しいことを検証できるようにします。設計上、DNSSECはリクエストとレスポンスのプライバシーを保護しません。従来、プライバシーはDNSトラフィックの要件とは見なされていないか、ネットワークトラフィックが十分にプライベートであると仮定されていました。しかし、最近の出来事 [RFC7258] により、これらの認識は変化しています。

DNSクライアントとサーバー間の暗号化の可能性を提供してきた他の取り組みには、DNSCurve [DNSCurve]、DNSCrypt [DNSCRYPT-WEBSITE]、Confidential DNS [CONFIDENTIAL-DNS]、およびIPSECA [IPSECA] が含まれます。本仕様に加えて、DPRIVEワーキンググループは、DNS over Datagram Transport Layer Security (DTLS) の提案 [DNSoD] も採用しています。

本文書は、既知のポート (well-known port) でDNS over TLSを使用することについて記述し、DNSでTCPとTLSを使用する際のオーバーヘッドを最小限に抑えるためのパフォーマンス考慮事項に関する助言を提供します。

DNS over TLSの開始は非常に簡単です。既知のポートで接続を確立することにより、クライアントとサーバーはチャネルを保護するためにTLSセッションをネゴシエートすることを期待し、合意します。展開は段階的に行われます。すべてのサーバーがDNS over TLSをサポートするわけではなく、既知のポートが一部のファイアウォールによってブロックされる可能性があります。クライアントは、TLSをサポートするサーバーとサポートしないサーバーを追跡することが期待されます。クライアントとサーバーは、[BCP195] のTLS実装推奨事項とセキュリティ考慮事項に従います。

ここで説明されているプロトコルは、スタブクライアント (stub clients) と再帰サーバー (recursive servers) 間のクエリとレスポンスに対して機能します。再帰クライアントと権威サーバー間の通信にも同様に機能する可能性がありますが、このプロトコルの適用は、現在の憲章に基づくDNS PRIVate Exchange (DPRIVE) ワーキンググループの範囲外です。

本文書は第4節で、異なるレベルのプライバシー保証を提供する2つのプロファイル (profiles) について記述しています: 日和見的プライバシープロファイル (opportunistic privacy profile) と帯域外キー固定プライバシープロファイル (out-of-band key-pinned privacy profile)。[TLS-DTLS-PROFILES] に基づく将来の文書が、DNS over TLSとDNS over DTLSの追加のプライバシープロファイルをさらに記述することが期待されています。

本文書の以前のドラフト版では、DNS-over-TCP接続をDNS-over-TLSセッションにアップグレードする技術、本質的には「DNSのためのSTARTTLS」について記述していました。プロトコルを簡素化するために、本文書では現在、TLS使用を指定するために既知のポートのみを使用し、アップグレード方式を省略しています。アップグレード方式はもはや本文書には現れず、現在は既知のポートを使用したDNS over TLSの使用にのみ焦点を当てています。