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 提供相同的目标主机和端口时, 客户端可以使用到该服务器的单个 DSO 会话来同时进行 DNS Updates 和 DNS Push Notification 订阅。DNS Updates 和 DNS Push Notifications 可以在同一目标主机的不同端口上处理, 在这种情况下, 就本规范而言, 它们不被视为"同一服务器", 与这两个端口的通信是独立处理的。在同一服务器上支持 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 客户端不应该常规性地保持 DNS Push Notification 订阅每天 24 小时、每周 7 天处于活动状态, 仅仅是为了在内存中保持列表更新, 以便如果用户确实选择调出该数据的屏幕显示, 可以非常快速地显示它。DNS Push Notifications 的设计足够快, 无需预加载"预热"列表在内存中, 以防以后可能需要它。

通常, 如 DNS Stateful Operations 规范 [RFC8490] 中所述, 如果客户端在该会话上没有活动的订阅 (或其他操作), 则客户端不得无限期地保持到服务器的 DSO 会话打开。客户端应该在 DSO 会话变为空闲后立即开始关闭它, 然后, 如果将来需要, 在需要时打开新会话。或者, 客户端可以推测性地将空闲 DSO 会话保持打开一段时间, 但受到约束, 即它不得保持空闲时间超过会话的空闲超时 (默认为 15 秒) [RFC8490] 的会话打开。

请注意, 具有活动 DNS Push Notification 订阅的 DSO 会话不被视为空闲, 即使在很长一段时间内没有流量流动。在这种情况下, DSO 不活动超时不适用, 因为会话不是不活动的, 但 keepalive 间隔仍然适用, 以确保生成足够的消息来维护中间盒 (例如 NAT 网关或防火墙) 中的状态, 并且使客户端和服务器能够定期验证它们仍然彼此连接。这在 DSO 规范 [RFC8490] 的第 6.2 节中描述。