DNS over Transport Layer Security(DoT)は、RFC 7858で定義されているように、TCPポート853上のTLSを使用してクライアントとリゾルバー間のDNSトラフィックを暗号化するネットワークプロトコルであり、経路上の傍受者がクエリを読み取ったり改ざんしたりすることを防止します。 DoTは、標準的なDNSメッセージを暗号化されたTLSセッションで包むことで、クライアントからリゾルバーへのホップを保護しますが、リゾルバーによる権威サーバーへのその後のルックアップを保護するものではなく、DNS応答の検証も行いません。これらの機能はDNSSECによって別途処理されます。 ゲストネットワーク、支社、およびリモートワーカーを管理する企業環境において、DoTは専用ポートとファイアウォール制御の容易さを通じて、DNS over HTTPS(DoH)に比べて運用上の利点を提供します。ただし、導入を成功させるには、慎重な証明書管理、明確なリゾルバーポリシー、および厳格モードとオポチュニスティックモードの設定を適切に処理し、暗号化されていないクエリへのサイレントフォールバックを回避する必要があります。
DNS over TLSの仕組み
DoTは、通常のDNSメッセージを平文ではなく、暗号化されたTLSセッションを介して送信します。DNSメッセージの形式は変更されず、変更されるのは転送方法のみです。
- TCP接続の確立:クライアントは、RFC 7858でDoT用に予約されているTCPポート853を介してリゾルバーに接続します。
- TLSハンドシェイクを完了する:クライアントとリゾルバーがTLSパラメータをネゴシエートし、リゾルバーが証明書を提示します。RFC 8310のユースケースプロファイルに応じて、クライアントはリゾルバーの身元を検証するか(厳格モード)、認証されていないセッションを受け入れるか(機会主義モード)のいずれかを行います。
- クエリの送信:クライアントは、DNS over TCPと同様に、2バイトの長さフィールドを先頭に付加した標準的なDNSメッセージを、暗号化されたセッションを通じて送信します。
- 応答の受信:リゾルバーは、同じセッションを通じて DNS 応答を返します。経路上の観察者は、暗号化されたトラフィックしか確認できません。
- セッションの再利用または終了:クライアントは接続を開いたままにし、その接続を介してさらなるクエリを送信することができます。これにより、検索のたびにハンドシェイクを繰り返す必要がなくなります。
DoTが保護するのは、クライアントとリゾルバー間のホップのみです。リゾルバー自身が権威サーバーに対して行うルックアップは別の経路であり、DoTの対象外となります。また、DoTは応答の妥当性を検証しません。その役割はDNSSECが担っています。
DNS over TLSの一般的な問題
多くのファイアウォールやゲストネットワークでは、送信元のTCP 853ポートへの通信が遮断されるため、DoTクエリはタイムアウトします。厳格モードでは、クライアントがホスト名の解決に失敗する可能性があり、機会主義モードでは、何も通知せずに平文通信にフォールバックする可能性があります。
厳格モードでは、リゾルバーの証明書は、設定された名前と、信頼されたCAへの証明書チェーンと一致している必要があります。有効期限が切れた証明書、中間証明書の欠落、またはクライアントから信頼されていない内部CAがあると、ハンドシェイクエラーや解決機能の停止が発生します。
TLSセッションを確立できない「オポチュニスティックなクライアント」は、警告なしに暗号化されていないクエリを送信する場合があります。ユーザーはDNSが保護されていると信じていますが、経路上の監視者は依然としてその内容を読み取ることができます。
外部リゾルバに送信された暗号化されたクエリは、内部のDNSフィルタリング、ロギング、およびスプリットホライズン応答をバイパスします。内部のホスト名に対してはNXDOMAINが返されるか、クライアントが承認されたDoTリゾルバに誘導されるまで、ポリシー制御はスキップされます。
DoTを終了させるリゾルバーは、多くの長期にわたるTCPおよびTLSセッションを開いたままにしておく必要があります。接続制限が不十分だったり、アイドルタイムアウトが短すぎたりすると、リクエストが集中する際にリセットが発生し、遅延が増大します。