跳到主要内容

6.1. Discovery (发现)

6.1. Discovery (发现)​

建立 DNS Push Notification 订阅的第一步是发现一个支持所需区域 DNS Push Notifications 的适当 DNS 服务器。

客户端首先向其正常配置的 DNS 递归解析器打开一个 DSO 会话, 并请求一个 Push Notification 订阅。此连接建立到 TCP 端口 853, 即 DNS over TLS [RFC7858] 的默认端口。如果 Push Notification 订阅请求成功, 且递归解析器尚未针对该名称、类型和类拥有活跃订阅, 则递归解析器将代表客户端创建相应的 Push Notification 订阅。接收到的结果将中继给客户端。这与客户端向其配置的 DNS 递归解析器发送普通 DNS 查询的方式非常类似, 如果递归解析器的缓存中尚未有适当的答案, 它会发出上游查询来满足请求。

在许多情况下, 递归解析器将能够处理客户端可能需要跟踪的所有名称的 Push Notifications。VPN 隧道和 Private DNS [RFC8499] 的使用可能会在客户端软件中增加一些额外的复杂性; 处理 DNS Push Notifications 的 VPN 隧道和 Private DNS 的技术与已经用于处理普通 DNS 查询的技术相同。

如果递归解析器不支持 DNS over TLS, 或支持 DNS over TLS 但未在 TCP 端口 853 上监听, 或在 TCP 端口 853 上支持 DNS over TLS 但该端口不支持 DSO, 则 DSO 会话建立将失败 [RFC8490]。

如果递归解析器在 TCP 端口 853 上支持 DSO 但不支持 Push Notification 订阅, 则当客户端尝试创建订阅时, 服务器将返回 DSO 错误代码 DSOTYPENI (11)。

在某些情况下, 递归解析器可能支持 DSO 和 Push Notification 订阅, 但可能无法为特定名称订阅 Push Notifications。在这种情况下, 递归解析器应该向客户端返回 SERVFAIL。这包括无法建立到区域的 DNS Push Notification 服务器的连接, 或建立了连接但收到非成功响应代码。在某些情况下, 如果客户端与区域所有者有预先建立的信任关系 (不是通过 VPN 软件的通常机制处理), 客户端可以通过直接联系区域的 DNS Push Notification 服务器来处理这些失败。

在上述任何情况下, 如果客户端无法通过其配置的递归解析器建立 DNS Push Notification 订阅, 客户端应继续发现用于直接通信的适当服务器。客户端必须确定服务器在哪个 TCP 端口监听连接, 这不一定是 (通常也不是) TCP 端口 53 (传统用于常规 DNS) 或 TCP 端口 853 (传统用于 DNS over TLS)。

这里描述的发现算法是一种迭代算法, 从客户端希望订阅的记录的完整名称开始。然后发出连续的 SOA 查询, 每次修剪一个标签, 直到发现最近的封闭权威服务器。还有一个优化, 使客户端能够在许多情况下直接"捷径"到最近封闭权威服务器的 SOA 记录。

  1. 客户端通过向其本地解析器发送 DNS 查询来开始发现, 记录类型为 SOA [RFC1035], 针对它希望订阅的记录名称。例如, 假设客户端希望订阅名称为 "_ipp._tcp.headoffice.example.com" 的 PTR 记录 (以发现在 Example Company 总部宣传的 Internet Printing Protocol (IPP) 打印机 [RFC8010] [RFC8011])。客户端首先向本地递归解析器发送对 "_ipp._tcp.headoffice.example.com" 的 SOA 查询。目标是确定对名称 "_ipp._tcp.headoffice.example.com" 具有权威性的服务器。包含名称 "_ipp._tcp.headoffice.example.com" 的最近封闭 DNS 区域可能是 "example.com", 或 "headoffice.example.com", 或 "_tcp.headoffice.example.com", 甚至 "_ipp._tcp.headoffice.example.com"。客户端事先不知道最近的封闭区域切割在哪里发生, 这就是它使用这里描述的迭代过程来发现此信息的原因。

  2. 如果请求的 SOA 记录存在, 它将在 Answer Section 中以 NOERROR 响应代码返回, 客户端已成功发现其所需的信息。(这种语言没有对 DNS 递归解析器提出任何新要求。此文本仅描述 DNS 协议 [RFC1034] [RFC1035] 的现有操作。)

  3. 如果请求的 SOA 记录不存在, 客户端将收到 NOERROR/NODATA 响应或 NXDOMAIN/Name Error 响应。在任何一种情况下, 本地解析器通常会在 Authority Section 中包含请求名称的最近封闭区域的 SOA 记录。如果在 Authority Section 中收到 SOA 记录, 则客户端已成功发现其所需的信息。(这种语言没有对 DNS 递归解析器提出任何新要求。此文本仅描述关于否定响应的 DNS 协议的现有操作 [RFC2308]。)

  4. 如果客户端收到不包含 SOA 记录的响应, 则它继续使用迭代方法。客户端从当前查询名称中删除前导标签, 如果结果名称中至少有两个标签, 则客户端为该新名称发送 SOA 查询, 并在上面的步骤 2 继续处理, 重复迭代搜索, 直到收到 SOA 或查询名称由单个标签组成, 即顶级域 (TLD)。在单标签名称 (TLD) 的情况下, 这是一个网络配置错误, 不应该发生, 客户端放弃。客户端可以在客户端选择的稍后时间重试该操作, 例如在网络连接更改后。

  5. 一旦知道 SOA (通过在 Answer Section 或 Authority Section 中看到), 客户端发送类型为 SRV [RFC2782] 的 DNS 查询, 记录名称为 "_dns-push-tls._tcp.<zone>", 其中 <zone> 是发现的 SOA 记录的所有者名称。

  6. 如果相关区域设置为提供 DNS Push Notifications, 则此 SRV 记录必须存在。(如果此 SRV 记录不存在, 则该区域未按本文档中指定的方式正确配置 DNS Push Notifications。) SRV "target" 包含为区域提供 DNS Push Notifications 的服务器名称。联系服务器的端口号在 SRV 记录 "port" 字段中。目标主机的地址可以包含在 Additional Section 中, 但是, 在使用前应该对地址记录进行身份验证, 如第 7.2 节以及使用 DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records [RFC7673] 的规范中所述 (如果适用)。

  7. 可能返回多个 SRV 记录。在这种情况下, 返回的 SRV 记录中的 "priority" 和 "weight" 值用于确定联系服务器以进行订阅请求的顺序。如 SRV 规范 [RFC2782] 中所述, 首先联系具有最低 "priority" 的服务器。如果多个服务器具有相同的 "priority", "weight" 指示客户端应联系该服务器的加权概率。较高的权重具有较高的被选择概率。如果服务器不愿意接受订阅请求, 或在客户端确定的合理时间内无法访问, 则应联系后续服务器。

每次客户端创建新的 DNS Push Notification 订阅时, 它应该重复发现过程, 以确定该时间该订阅的首选 DNS 服务器。如果客户端已经与该 DNS 服务器有 DSO 会话, 客户端应该为新订阅重用该现有 DSO 会话; 否则, 建立新的 DSO 会话。客户端必须遵守在执行发现过程时收到的记录上的 DNS TTL 值, 并以此生命周期将它们存储在本地缓存中 (因为它通常会对其执行的所有 DNS 查询这样做)。这意味着, 只要权威记录上的 DNS TTL 值设置为合理的值, 客户端就可以使用仅本地存储的缓存数据实际瞬间完成发现过程的重复应用。

最后于 更新