3. Overview (概要)
3. Overview (概要)
DNS Push Notification クライアントは, 特定の RRset の適切な Push Notification サーバーに接続し, 関心のある RRset を示す DSO メッセージを送信することにより, その RRset の Push Notifications をサブスクライブします。クライアントがこれらのレコードのさらなる更新を受信することに興味を失った場合, サブスクライブを解除します。
DNS ゾーンの DNS Push Notification サーバーは, 名前の正しい変更通知を生成できる任意のサーバーです。プライマリ, セカンダリ, またはステルスネームサーバー [RFC8499] である可能性があります。
ゾーンの "_dns-push-tls._tcp.<zone>" SRV レコードは, そのゾーンの "_dns-update-tls._tcp.<zone>" SRV レコードと同じターゲットホストとポートを参照してもかまいません。DNS Updates と DNS Push Notifications の両方に同じターゲットホストとポートが提供されている場合, クライアントは DNS Updates と DNS Push Notification サブスクリプションの両方にそのサーバーへの単一の DSO セッションを使用してもかまいません。DNS Updates と DNS Push Notifications は同じターゲットホスト上の異なるポートで処理される場合があり, その場合, この仕様の目的では「同じサーバー」とは見なされず, これら 2 つのポートとの通信は独立して処理されます。同じサーバーで DNS Updates と DNS Push Notifications をサポートすることはオプションです。DNS Push Notification サーバーは DNS Update をサポートする必要はありません。
標準の DNS クエリは, DNS Push Notification (すなわち DSO) セッション上で送信してもかまいません。サーバーが権威を持つ任意のゾーンについて, そのゾーン内に該当する名前のクエリ (例えば, "_dns-push-tls._tcp.<zone>" SRV レコード) に対して, 通常の DNS クエリと DNS Push Notification サブスクリプションの両方について権威的に応答しなければなりません。サーバーが再帰リゾルバーとして機能している名前 (例えば, サーバーがローカル再帰リゾルバーである場合) について, DNS Push Notification サブスクリプションをサポートする任意のクエリについて, 標準クエリもサポートしなければなりません。
DNS Push Notifications は, 高速ポーリングよりも応答サーバーへの負荷が少なくなりますが, Push Notifications にはまだコストがかかります。したがって, DNS Push Notification クライアントは, 無謀に過剰な数の Push Notification サブスクリプションを作成してはなりません。具体的には:
(a) サブスクリプションは, ライブデータが必要な正当な理由がある場合にのみアクティブにする必要があります (例えば, 画面表示が現在ユーザーに結果を表示している場合), そして, そのデータの必要性が終了するとすぐにサブスクリプションをキャンセルする必要があります (例えば, ユーザーがその表示を閉じたとき)。スマートフォンのようなデバイスの場合, 一定期間の非アクティブ後にスリープ状態になるか, 画面を暗くする場合, 画面を暗くするときにサブスクリプションをキャンセルする必要があります (ユーザーはいずれにせよディスプレイ上の変更を見ることができないため), そして, ディスプレイスリープから復帰したときにサブスクリプションを再開する必要があります。
(b) DNS Push Notification クライアントは, ユーザーがそのデータの画面表示を呼び出すことを選択した場合に非常に高速に表示できるように, メモリ内のリストを最新の状態に保つためだけに, 週 7 日 24 時間 DNS Push Notification サブスクリプションをアクティブに保つことを日常的に行うべきではありません。DNS Push Notifications は, 後で必要になる可能性がある場合に備えてメモリに「ウォーム」リストを事前ロードする必要がないほど十分に高速に設計されています。
一般的に, DNS Stateful Operations 仕様 [RFC8490] で説明されているように, そのセッション上にアクティブなサブスクリプション (または他の操作) がない場合, クライアントはサーバーへの DSO セッションを無期限に開いたままにしてはなりません。クライアントは, DSO セッションがアイドル状態になった直後に閉じ始める必要があり, その後, 将来必要な場合は, 必要なときに新しいセッションを開く必要があります。あるいは, クライアントは, アイドル DSO セッションを一定期間推測的に開いたままにしてもかまいませんが, セッションのアイドルタイムアウト (デフォルトでは 15 秒) [RFC8490] を超えてアイドル状態になっているセッションを開いたままにしてはならないという制約があります。
アクティブな DNS Push Notification サブスクリプションを持つ DSO セッションは, 長期間トラフィックが流れていない場合でも, アイドル状態とは見なされないことに注意してください。この場合, DSO 非アクティブタイムアウトは適用されません。なぜなら, セッションは非アクティブではないからですが, keepalive 間隔は依然として適用され, ミドルボックス (NAT ゲートウェイやファイアウォールなど) の状態を維持するために十分なメッセージの生成を確保し, クライアントとサーバーが互いに接続性を定期的に検証できるようにします。これは DSO 仕様 [RFC8490] のセクション 6.2 で説明されています。