3. Establishing and Managing DNS-over-TLS Sessions (DNS-over-TLSセッションの確立と管理)
3.1 Session Initiation (セッション開始)
デフォルトでは、DNS over TLSをサポートするDNSサーバーは、DNS over TLSに853以外のポートを使用することについてクライアントと相互に合意していない限り、ポート853でTCP接続をリッスンし、受け入れなければなりません (MUST)。853以外のポートを使用するためには、クライアントとサーバーの両方がソフトウェアに設定オプションを持つ必要があります。
デフォルトでは、特定のサーバーからDNS over TLSによるプライバシーを望むDNSクライアントは、DNS over TLSに853以外のポートを使用することについてサーバーと相互に合意していない限り、サーバーのポート853へのTCP接続を確立しなければなりません (MUST)。そのような別のポートは、ポート53であってはならず (MUST NOT)、「先着順 (first-come, first-served)」ポート範囲からのものであってもよい (MAY) です。DNS over TLSにポート53を使用しないというこの推奨事項は、TLSの使用または非使用の選択における複雑さを回避し、ダウングレード攻撃のリスクを軽減するためです。このTCP接続での最初のデータ交換は、[RFC5246] に記述されている手順を使用して、クライアントとサーバーがTLSハンドシェイクを開始することでなければなりません (MUST)。
DNSクライアントとサーバーは、ポート853を使用して平文DNSメッセージを転送してはなりません (MUST NOT)。DNSクライアントは、DNS over TLSに使用されるポート (例えば、TLSハンドシェイク失敗後を含む) で平文DNSメッセージを送信してはならず (MUST NOT)、DNSサーバーは応答してはなりません (MUST NOT)。保護されたデータと保護されていないデータを混在させることには重大なセキュリティ問題があり、このため、特定のサーバーによってDNS over TLS用に指定されたポートのTCP接続は、純粋に暗号化された通信のために予約されています。
DNSクライアントは、タイムアウト、接続拒否、TLSハンドシェイク失敗を含む、DNS over TLSをサポートしないサーバーIPアドレスを記憶し、合理的な期間 (サーバーごとに1時間など)、それらからDNS over TLSを要求しないことが推奨されます (SHOULD)。帯域外キー固定プライバシープロファイル (セクション4.2) に従うDNSクライアントは、DNS-over-TLS接続失敗の再試行についてより積極的であってもよい (MAY) です。
3.2 TLS Handshake and Authentication (TLSハンドシェイクと認証)
DNSクライアントがDNS over TLSの既知のポートでTCP経由の接続に成功すると、[BCP195] で規定されているベストプラクティスに従って、TLSハンドシェイク [RFC5246] を続行します。
その後、クライアントは、必要に応じてサーバーを認証します。本文書は、認証のための新しいアイデアを提案するものではありません。使用中のプライバシープロファイル (セクション4) に応じて、DNSクライアントは、サーバーの認証を要求しないことを選択するか、信頼されたSubject Public Key Info (SPKI) フィンガープリントピンセットを利用することができます。
TLSネゴシエーションが完了すると、接続は暗号化され、盗聴から保護されるようになります。
3.3 Transmitting and Receiving Messages (メッセージの送受信)
確立されたTLSセッション内のすべてのメッセージ (リクエストとレスポンス) は、[RFC1035] のセクション4.2.2に記述されている2オクテット長フィールドを使用しなければなりません (MUST)。効率の理由から、DNSクライアントとサーバーは、2オクテット長フィールドとその長フィールドによって記述されるメッセージを、同時にTCP層に渡すべきです (SHOULD) (例えば、単一の「write」システムコールで)。これにより、すべてのデータが単一のTCPセグメントで送信される可能性が高くなります ([RFC7766]、セクション8)。
レイテンシを最小限に抑えるために、クライアントはTLSセッション上で複数のクエリをパイプライン化すべきです (SHOULD)。DNSクライアントがサーバーに複数のクエリを送信する場合、次のクエリを送信する前に未解決の応答を待つべきではありません ([RFC7766]、セクション6.2.1.1)。
パイプライン化されたレスポンスは順不同で到着する可能性があるため、クライアントは、メッセージID (Message ID) を使用して、同じTLS接続上の未解決のクエリにレスポンスをマッチングしなければなりません (MUST)。レスポンスに質問セクション (Question Section) が含まれている場合、クライアントはQNAME、QCLASS、およびQTYPEフィールドをマッチングしなければなりません (MUST)。クライアントが未解決のクエリにレスポンスを適切にマッチングできないと、相互運用性に深刻な影響を及ぼす可能性があります ([RFC7766]、セクション7)。
3.4 Connection Reuse, Close, and Reestablishment (接続の再利用、クローズ、および再確立)
「getaddrinfo()」や「gethostbyname()」などのライブラリ関数を使用するDNSクライアントの場合、現在の実装は、各DNSクエリごとにTCP接続を開閉することが知られています。各クエリに対して単一のクエリを持つ過剰なTCP接続を回避するために、クライアントは再帰リゾルバへの単一のTCP接続を再利用すべきです (SHOULD)。あるいは、同じマシン上のDNS-over-TLS対応キャッシングリゾルバへのUDPを使用し、そのリゾルバがシステム全体のTCP接続を再帰リゾルバに使用することを好む場合があります。
TCPおよびTLS接続のセットアップコストを償却するために、クライアントとサーバーは、各レスポンスの後に直ちに接続を閉じるべきではありません (SHOULD NOT)。代わりに、クライアントとサーバーは、十分なリソースがある限り、後続のクエリのために既存の接続を再利用すべきです (SHOULD)。場合によっては、これは、クライアントとサーバーがアイドル接続をある程度の時間開いたままにしておく必要があることを意味する場合があります。
確立された接続とアイドル接続の適切な管理は、DNSサーバーの健全な運用にとって重要です。DNS over TLSの実装者は、[RFC7766] に記述されているように、DNS over TCPのベストプラクティスに従うべきです (SHOULD)。これを怠ると、リソース枯渇とサービス拒否につながる可能性があります。
[RFC1035] の時代からのクライアントとサーバーの実装は、TCP接続管理が不十分であることが知られていますが、本文書では、TLSのネゴシエーション成功は、TLSなしのDNS over TCPのタイムアウトやその他の推奨事項とは独立して、双方がアイドルDNS接続を開いたままにする意欲を示すことを規定しています。つまり、このプロトコルを実装するソフトウェアは、アイドルで永続的な接続をサポートし、複数の、潜在的に長寿命のTCP接続を管理する準備ができていると想定されます。
本文書は、アイドル接続のタイムアウト値について特定の推奨事項を作成しません。クライアントとサーバーは、利用可能なリソースのレベルに応じて、接続を再利用および/またはクローズすべきです。タイムアウトは、アクティビティが低い期間中はより長く、アクティビティが高い期間中はより短くなる可能性があります。この分野での現在の取り組みは、DNS-over-TLSクライアントとサーバーが有用なタイムアウト値を選択する際にも役立つ可能性があります [RFC7828] [TDNS]。
アイドル接続を開いたままにするクライアントとサーバーは、いずれかの当事者によるアイドル接続の終了に対して堅牢でなければなりません (MUST)。現在のDNS over TCPと同様に、DNSサーバーは (おそらくリソースの制約により) いつでも接続を閉じてもよい (MAY) です。現在のDNS over TCPと同様に、クライアントは突然のクローズを処理し、接続を再確立および/またはクエリを再試行する準備をしなければなりません (MUST)。
[RFC7766] で議論されているように、終了したDNS-over-TCP接続を再確立する際には、TCP Fast Open [RFC7413] が有益です。DNS-over-TLSポートで暗号化されたDNSデータのみを送信するという要件を強調すると (セクション3.2)、TCP Fast Openを使用する場合、クライアントとサーバーは直ちにTLSハンドシェイクを開始または再開しなければなりません (MUST) (平文DNSを交換してはなりません (MUST NOT))。DNSサーバーは、高速TLSセッション再開 [RFC5077] を有効にすべきであり (SHOULD)、これは接続を再確立する際に使用されるべきです (SHOULD)。
接続を閉じる際、DNSサーバーは、TCP TIME-WAIT状態をクライアントにシフトするために、TLS close-notifyリクエストを使用すべきです (SHOULD)。DNS over TCPを最適化するための追加の要件とガイダンスは、[RFC7766] によって提供されています。