1. Introduction (はじめに)

ドメインネームシステム (Domain Name System, DNS) の概念は、"Domain names - concepts and facilities" [RFC1034] で規定されています。UDP および TCP 上での DNS クエリとレスポンスの送信は、"Domain names - implementation and specification" [RFC1035] で規定されています。

本文書は、QUIC トランスポート (QUIC Transport) [RFC9000] [RFC9001] 上での DNS プロトコルのマッピングを提示します。DNS over QUIC は、"DNS Terminology" [DNS-TERMS] に沿って、ここでは DoQ と呼ばれます。

DoQ マッピングの目標は以下の通りです:

DoT [RFC7858] と同じ DNS プライバシー保護を提供すること。これには、"Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310] で規定されている認証ドメイン名によってクライアントがサーバーを認証するオプションが含まれます。
従来の DNS over UDP と比較して、DNS サーバーに対する改善された送信元アドレス検証レベルを提供すること。
送信できる DNS レスポンスのサイズにパス MTU 制限を課さないトランスポートを提供すること。

これらの目標を達成し、DNS の暗号化に関する進行中の作業をサポートするために、本文書の範囲には以下が含まれます:

"stub to recursive resolver" シナリオ (本文書では "stub to recursive" シナリオとも呼ばれます)
"recursive resolver to authoritative nameserver" シナリオ (本文書では "recursive to authoritative" シナリオとも呼ばれます)、および
"nameserver to nameserver" シナリオ (主にゾーン転送 (XFR) [RFC1995] [RFC5936] に使用されます)

言い換えれば、本文書は QUIC を DNS の汎用トランスポートとして規定します。

本文書の具体的な非目標は以下の通りです:

ミドルボックスによる DoQ トラフィックの潜在的なブロッキングを回避する試みは行いません。
DNS Stateful Operations (DSO) [RFC8490] でのみ使用されるサーバー起動トランザクションをサポートする試みは行いません。

QUIC 上でのアプリケーションの送信を規定するには、アプリケーションのメッセージが QUIC ストリームにどのようにマッピングされるか、および一般的にアプリケーションが QUIC をどのように使用するかを規定する必要があります。これは、"Hypertext Transfer Protocol Version 3 (HTTP/3)" [HTTP/3] で HTTP に対して行われています。本文書の目的は、DNS メッセージが QUIC 上で送信される方法を定義することです。

DNS over HTTPS (DoH) [RFC8484] は、HTTP/3 と共に使用して QUIC の利点の一部を得ることができます。しかし、DoQ の軽量な直接マッピングは、再帰から権威へのシナリオおよびゾーン転送シナリオの両方に対してより自然な適合と見なすことができます。これらのシナリオでは、仲介者が関与することはほとんどありません。これらのシナリオでは、HTTP の追加オーバーヘッドは、例えば HTTP プロキシやキャッシング動作の利点によって相殺されません。

本文書では、第 3 節で提案された設計を導いた推論を提示します。第 4 節では DoQ の実際のマッピングを規定します。第 5 節では DoQ の実装、使用、および展開に関するガイドラインを提示します。