跳到主要内容

5. 资源记录集 (Resource Record Sets)

每个 DNS 资源记录 (Resource Record, RR) 都有标签 (label)、类 (class)、类型 (type) 和数据 (data)。两个记录的标签、类、类型和数据都相等是没有意义的 —— 服务器在遇到此类重复时应该 (should) 抑制它们。但是, 对于大多数记录类型, 可以存在具有相同标签、类、类型但数据不同的记录。此类记录组在此定义为资源记录集 (Resource Record Set, RRSet)。

5.1. 从 RRSet 发送 RR (Sending RRs from an RRSet)​

对特定 (或非特定) 标签、类、类型的查询应始终返回相关 RRSet 中的所有记录 —— 无论是一个 RR 还是多个 RR。如果整个 RRSet 不适合响应, 则响应必须 (must) 标记为"截断"(truncated)。

5.2. RRSet 中 RR 的 TTL (TTLs of RRs in an RRSet)​

资源记录也有生存时间 (Time to Live, TTL)。RRSet 中的 RR 可能具有不同的 TTL。没有发现任何无法以其他方式更好实现的用途。但是, 这可能导致来自缓存服务器的部分响应 (未标记为"截断"), 其中 RRSet 中某些 RR 的 TTL 已过期。

因此, 在 RRSet 中使用不同的 TTL 是不推荐的, RRSet 中所有 RR 的 TTL 必须 (must) 相同。

如果客户端收到包含具有不同 TTL 的 RRSet 中 RR 的响应, 则应该 (should) 将其视为错误。如果所涉及的 RRSet 来自此数据的非权威来源, 则客户端应该 (should) 简单地忽略该 RRSet, 并在需要该值时从权威来源获取。权威来源发送此类格式错误的 RRSet 时, 客户端应该 (should) 将 RRSet 中的所有 RR 视为 RRSet 中所有 TTL 都设置为 RRSet 中最小 TTL 值的情况。在任何情况下, 服务器不得 (may not) 发送 TTL 不全相等的 RRSet。

5.4. 接收 RRSet (Receiving RRSets)​

服务器绝不能 (must never) 将来自响应的 RR 与缓存中的 RR 合并以形成 RRSet。如果响应包含与服务器缓存中的数据形成 RRSet 的数据, 则服务器必须 (must) 忽略响应中的 RR, 或丢弃当前缓存中的整个 RRSet。

5.4.1. 数据排名 (Ranking data)​

在考虑是接受响应中的 RRSet 还是保留缓存中已有的 RRSet 时, 服务器应该 (should) 考虑各种数据的相对可信度。来自响应的权威响应应该 (should) 替换从先前响应的附加信息中获取的缓存数据。

可用数据的准确性从其来源推断。可信度从最高到最低的顺序如下:

  • 来自主区域文件的数据 (粘合数据除外)
  • 来自区域传输的数据 (粘合数据除外)
  • 权威响应的应答部分中包含的权威数据
  • 来自权威响应的权威部分的数据
  • 来自主区域或区域传输的粘合数据
  • 来自非权威响应的应答部分的数据, 以及来自权威响应的应答部分的非权威数据
  • 来自权威响应的附加信息
  • 来自非权威响应的权威部分的数据
  • 来自非权威响应的附加信息

5.5. 发送 RRSet (再述) (Sending RRSets (reprise))​

资源记录集在任何 DNS 响应中应该 (should) 只包含一次。如有必要, 它可以 (may) 出现在响应、权威或附加信息部分中的任何一个。但是, 除非规范明确要求, 否则不应该 (should not) 在相同或其他部分中重复。

最后于 更新