8. Security Considerations (セキュリティの考慮事項)

DNS over TLSの使用は、DNSメッセージの盗聴能力から生じるプライバシーリスクに対処するように設計されています。DNSの他のセキュリティ問題には対処しておらず、プライバシー保護の成功に影響を与える可能性のある残存リスクが多数あります:

TLSには、中間者攻撃やプロトコルダウングレードなどの既知の攻撃があります。これらはTLSに対する一般的な攻撃であり、DNS over TLSに特有のものではありません。これらのセキュリティ問題の議論については、TLS RFCを参照してください。クライアントとサーバーは、[BCP195] のTLS実装推奨事項とセキュリティ考慮事項に従わなければなりません (MUST)。TLSをサポートすることが知られているサーバーを追跡するDNSクライアントは、ダウングレード攻撃を検出できます。接続履歴がなく、TLSのサポートが明らかでないサーバーの場合、プライバシープロファイルとプライバシー要件に応じて、クライアントは (a) 利用可能な場合に別のサーバーを試す、(b) TLSなしで続行する、または (c) クエリの転送を拒否する、ことを選択できます。
ミドルボックス [RFC3234] は一部のネットワークに存在し、通常のDNS解決に干渉することが知られています。DNS over TLSに指定されたポートの使用は、そのような干渉を回避すべきです。一般的に、TLSを試行して失敗したクライアントは、プライバシープロファイルとプライバシー要件に応じて、暗号化されていないDNSにフォールバックするか、後で待機して再試行することができます。
平文で実行されるDNSプロトコルのインタラクションは、中間者攻撃者によって変更される可能性があります。たとえば、暗号化されていないクエリとレスポンスがクライアントとサーバー間でポート53を介して行われる可能性があります。このため、クライアントは、平文でアドバタイズされたサーバー機能に関するキャッシュされた情報を破棄してもよい (MAY) です。
本文書自体は、既知のトラフィック分析やサイドチャネルリークに抵抗するためのアイデアを規定していません。暗号化されたメッセージであっても、適切に位置する当事者は、メッセージのタイミングとサイズの分析から特定の詳細を収集できる可能性があります。クライアントとサーバーは、メッセージサイズによるプライバシー漏洩に対処するためのパディング方法の使用を検討してもよい (MAY) です [RFC7830]。トラフィック分析は多くの種類のパターンと多くの種類の分類器に基づく可能性があるため、単純なパディングスキームだけでは、そのような攻撃を軽減するのに十分ではない可能性があります。しかし、パディングは、時間の経過とともに開発される可能性のあるトラフィック分析攻撃に対するより複雑な軽減策の一部を形成します。パディングの使用方法に関して柔軟性を提供できる実装者は、そのような軽減策を将来展開できるようにするためのより良い立場にある可能性があります。

前述のように、DNSSECとDNS over TLSは独立した完全に互換性のあるプロトコルであり、それぞれ異なる問題を解決します。一方の使用は、他方の必要性や有用性を減少させるものではありません。