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长期查询 (DNS Long-Lived Queries, LLQ) 机制 [RFC8764] 是提供异步更改通知的现有已部署解决方案; 它被Apple的Back to My Mac [RFC6281] 服务使用, 该服务于2007年在Mac OS X 10.5 Leopard中引入。Back to My Mac是在数据中心运营人员断言服务器不可能处理大量TCP连接的时代设计的, 即使这些连接承载的流量很少并且大部分时间处于空闲状态。因此, LLQ被定义为基于UDP的协议, 有效地在用户空间中复制了TCP的许多连接状态管理逻辑, 并创建了自己对现有TCP功能 (如流量控制、可靠性和三次握手) 的模仿。

本文档基于LLQ协议获得的经验, 采用改进的设计。本规范使用运行在TLS over TCP之上的DNS有状态操作 (DNS Stateful Operations, DSO) [RFC8490], 而不是使用UDP, 因此不需要重新发明现有的TCP功能。使用TCP还使长期低流量连接能够更好地通过NAT网关存活, 而无需依赖网关支持NAT端口映射协议 (NAT Port Mapping Protocol, NAT-PMP) [RFC6886] 或端口控制协议 (Port Control Protocol, PCP) [RFC6887], 也不需要诉诸过度的保活流量。