2. Motivation (動機)

ドメインネームシステムが新しい用途や展開の変化に適応し続けるにつれて, ポーリングはネットワーク全体の多くのレベルでDNSサーバーに負担をかける可能性があります。他のネットワークプロトコルは, 観察者デザインパターン [OBS] に従って, パブリッシュ/サブスクライブモデルを正常に展開してきました。拡張可能メッセージングおよびプレゼンスプロトコル (Extensible Messaging and Presence Protocol, XMPP) パブリッシュ-サブスクライブ [XEP0060] とAtom [RFC4287] が例です。DNSサーバーは一般的に高度に調整されており, 高速のクエリ/レスポンストラフィックに対応できますが, DNSレコードの変更を追跡するためのパブリッシュ/サブスクライブモデルを追加することで, CPU使用量を削減し, ネットワークトラフィックを低減しながら, より迅速な変更通知を提供できます。

DNSプッシュ通知の指針となる設計原則は, DNSクエリによる繰り返しポーリングの代わりにDNSプッシュ通知を使用することを選択したクライアントは, 十分に高速なポーリングで得られるのと同じ結果を, より効率的に受け取るということです。これは, 特定のDNSプッシュ通知サブスクリプションと一致するレコードを決定するための規則が, 特定のDNSクエリと一致するレコードを決定するために使用される既に確立された規則と同じであることを意味します [RFC1034]。たとえば, 名前の比較は大文字と小文字を区別しない方法で行われ, ゾーン内のCNAMEタイプのレコードは, クエリまたはサブスクリプション内の任意のDNS TYPEと一致します。

マルチキャストDNS [RFC6762] 実装は常に, よく知られたリンクローカルIPマルチキャストグループアドレスでリッスンし, 変更はすべてのグループメンバーが受信できるように, そのマルチキャストグループアドレスに送信されます。したがって, マルチキャストDNSには既に非同期変更通知機能があります。DNSベースのサービスディスカバリー [RFC6763] がユニキャストDNSを使用して広域ネットワーク全体で使用される場合 (ディスカバリープロキシ [RFC8766] 経由で促進される可能性があります), ポーリングなしでDNSレコードの変更をタイムリーに知ることができるように, ユニキャストDNSに同等の機能を持つことが有益です。

DNS Long-Lived Queries (LLQ) メカニズム [RFC8764] は, 非同期変更通知を提供するための既存の展開済みソリューションです; これは, 2007年にMac OS X 10.5 Leopardで導入されたAppleのBack to My Mac [RFC6281] サービスで使用されました。Back to My Macは, データセンター運用スタッフが, これらの接続が非常に少ないトラフィックを運び, ほとんどの時間アイドル状態であっても, サーバーが大量のTCP接続を処理することは不可能であると主張していた時代に設計されました。その結果, LLQはUDPベースのプロトコルとして定義され, 実質的にユーザー空間でTCPの接続状態管理ロジックの多くを複製し, フロー制御, 信頼性, 3ウェイハンドシェイクなどの既存のTCP機能の独自の模倣を作成しました。

この文書は, LLQプロトコルで得られた経験に基づいて, 改善された設計を構築しています。UDPを使用する代わりに, この仕様はTLS over TCPで実行されるDNS Stateful Operations (DSO) [RFC8490] を使用するため, 既存のTCP機能を再発明する必要はありません。TCPを使用することで, 長期間の低トラフィック接続は, ゲートウェイがNAT Port Mapping Protocol (NAT-PMP) [RFC6886] またはPort Control Protocol (PCP) [RFC6887] をサポートすることに依存せず, 過度のキープアライブトラフィックに頼ることなく, NATゲートウェイを通じてより良い寿命を得ることができます。