7. Design Evolution (設計の進化)

本文書の以前のドラフト版では、TLSセッションを確立するためのアップグレードベースのアプローチを提案していました。クライアントは、DNS拡張メカニズム (Extensions Mechanisms for DNS, EDNS(0)) フラグフィールドに「TLS OK」ビットを設定することで、TLSへの関心を示します。サーバーは、TLS OKビットを設定して応答することで、その受け入れを示します。

クライアントはチャネルを保護する前に情報を漏洩 (リーク) したくないと仮定しているため、この目的のためにクライアントが送信できる「ダミークエリ (dummy query)」の使用を提案しました。提案されたクエリ名はSTARTTLS、クエリタイプはTXT、クエリクラスはCHでした。

TLS OKシグナリングアプローチには、利点と欠点の両方があります。重要な利点の1つは、クライアントとサーバーがTLSをネゴシエートできることです。サーバーが忙しすぎる場合、または特定のクライアントにTLSサービスを提供したくない場合、TLSプローブに否定的に応答できます。付随的な利点は、サーバーが実装と展開の前に、DNS over TLSの採用に関する情報を (クエリのTLS OKビットを介して) 収集できることです。もう1つの予想される利点は、DNS over TLSがポート53で動作するという期待です。つまり、別のポートを「無駄にする」必要がなく、ミドルボックスに新しいファイアウォールルールを展開する必要もありません。

しかし、同時に、EDNS0フラグフィールドが長年変更されていないことを考えると、ミドルボックスがTLS OKビットを通過させるかどうかについて不確実性がありました。別の欠点は、TLS OKビットがダウングレード攻撃を容易にし、壊れたミドルボックスと区別がつかなくなる可能性があることです。パフォーマンスの観点からは、アップグレードベースのアプローチには、ダミークエリのために1xRTTの追加レイテンシを必要とするという欠点がありました。

この提案に続いて、DNS over DTLSが個別に提案されました。DNS over DTLSは、ポート53で動作できると主張しましたが、それは非DTLSサーバーがDNS-over-DTLSクエリをレスポンスとして解釈するためだけでした。つまり、非DTLSサーバーは、QRフラグが1に設定されていることを観察します。これは技術的には機能しますが、不幸であり、おそらく望ましくないように思えます。

DNS over TLSとDTLSの両方は、単一の既知のポートから利益を得ることができ、追加のレイテンシと誤解されたレスポンスとしてのクエリを回避できます。