2020/04/28 追記
仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。
「Specification of DNS over Dedicated QUIC Connections」
QUICの標準化とアプリケーションレイヤ
IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。
標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。
とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者にQUICについてよく発表しているGoogleの方や、SalesforceやFastlyの人もいる。
Specification of DNS over QUIC
「Specification of DNS over QUIC」として書かれている。
主な目標として下記があげれている
- DNS over TLS(RFC7858)と同等のプライバシ保護を提供する。DNS通信の保護を議論している、DPRIVE WGで議論している「Authentication and (D)TLS Profile for DNS-over-(D)TLS」を含み、ドメイン名の権威をもつサーバとしての認証を行う。
- DNS over UDP(RFC1035)と比べて、送信元IPの検証を提供する
- 経路のMTUによって送れるDNSレスポンスを制限しないようなトランスポートを提供する
- DNS over UDPやDNS over TLSと対比してパフォーマンスの向上を検討する
- HTTPとは異なるQUICの利用について概説し、QUICプロトコルとそのAPI定義に参加する
上記の目標のために、想定する通信はスタブリゾルバからリカーシブルリゾルバの通信を想定し、ゾーン転送は考慮しない。中間装置によるブロックを考慮しないことが挙げられている。
HTTP同様DNSでもレイテンシを小さくするため、0-RTTセッション再開、ロスリカバリのサポート、マルチストリームでヘッドオブラインブロッキングの回避の機能について言及がある。
仕様
ALPN識別子
ALPNで使用する識別子として、"qd"を使用する。HTTP同様、ハイフン付きでドラフトバージョンを指定する
ポート番号
具体的なポート番号はTBDとなっているが、DNS over UDPやDNS over DTLSとの混用を避けるため53, 853の使用は避けるようだ。サーバはそのポートでリッスンし、クライアントはそのポートにつなぎに行く。
ストリーム
各ストリームがDNSのリクエスト/レスポンスに相当する。クライアントから開始するストリームは、3, 5, ... と続く。
DNS Push NotificationsのようなサーバからPUSHメッセージを送ることも可能で、サーバから開始するストリームは2, 4, ...となる。クライアントはそのストリーム上で応答を返す。
プライバシの問題
DNS Privacy Considerations(RFC7626)で言及されていることは、DSN over TLSの場合と変わらないが、0RTT通信と、セッション再開について言及がある。
0-RTT セッション再開の再送攻撃
観測者は0-RTTを利用した問い合わせを再送することができます。これによりリカーシブルリゾルバから権威リゾルバへのクエリをトリガできます。リカーシブルリゾルバの振る舞いを観測できる場合は、0-RTTの問い合わせを再送させることができもともとの問い合わせを推測リスクが高まります。デフォルトでは無効にしとくことが好ましい。
セッション再開
QUICではIPアドレスが変わってもセッションを維持できるため、それらが同じクライアントだと識別可能です。セッション再開や長いセッションはパフォーマンス上有用だが、クライアントは考慮スべき。
