Skip to main content

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

每个DNS资源记录（RR）都有一个标签（label）、类（class）、类型（type）和数据（data）。两个记录的标签、类、类型和数据全部相等是没有意义的——服务器应该在遇到时抑制这样的重复。然而，对于大多数记录类型来说，可以存在具有相同标签、类和类型，但数据不同的记录。这样一组记录在此定义为资源记录集（RRSet）。

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

对特定（或非特定）标签、类和类型的查询将始终返回关联RRSet中的所有记录——无论是一个还是多个RR。如果整个RRSet无法放入响应中，则响应必须标记为"截断"（truncated）。

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

资源记录还有一个生存时间（TTL）。RRSet中的RR可能具有不同的TTL。尚未发现不能通过其他方式更好地完成的用途。然而，这可能导致来自缓存服务器的部分回复（未标记为"截断"），其中RRSet中某些但并非所有RR的TTL已过期。

因此，在RRSet中使用不同的TTL被弃用，RRSet中所有RR的TTL必须相同。

如果客户端收到的响应包含来自具有不同TTL的RRSet的RR，它应将其视为错误。如果相关的RRSet来自此数据的非权威源，客户端应简单地忽略该RRSet，如果需要这些值，则寻求从权威源获取它们。配置为将所有查询发送到一个或多个特定服务器的客户端应将这些服务器视为此目的的权威。如果权威源发送这样一个格式错误的RRSet，客户端应将RRSet的所有RR视为所有目的，就好像RRSet中的所有TTL都已设置为RRSet中最低TTL的值一样。在任何情况下，服务器都不能发送TTL不全部相等的RRSet。

5.3. DNSSEC Special Cases (DNSSEC特殊情况)​

DNS安全（DNSSEC）[RFC2065]添加的两种记录类型在考虑资源记录集的形成时需要特别注意。这些是SIG和NXT记录。应该注意的是，DNS安全仍然非常新，到目前为止，对它的经验很少。读者应该准备好本文档中包含的与DNSSEC相关的信息随着DNS安全规范的成熟而过时。

5.3.1. SIG records and RRSets (SIG记录和RRSet)​

SIG记录为DNS中的另一个RRSet提供签名（验证）数据。在区域已签名的地方，区域中的每个RRSet都将有一个与之关联的SIG记录。RRSet的数据类型包含在SIG RR的数据中，以指示此SIG记录与哪个特定RRSet相关联。如果应用上述规则，每当包含SIG记录以验证该响应时，与适当节点关联的所有其他RRSet的SIG记录也需要包含在内。在某些情况下，这可能是非常大量的记录，它们是相当大的RR也无济于事。

因此，特别允许权限部分仅包含那些"类型覆盖"（type covered）字段等于返回的答案的类型字段的SIG RR。然而，当在答案部分返回SIG记录时，响应对SIG记录的查询，或对与名称关联的所有记录的查询（type=ANY），必须包含整个SIG RRSet，就像任何其他RR类型一样。

在权限部分接收包含SIG记录的响应的服务器，或（可能不正确地）作为附加数据接收的服务器，必须理解几乎可以肯定没有包括整个RRSet。因此，它们不能以允许在该服务器收到SIG记录查询时返回该SIG记录的方式缓存该SIG记录。RFC2065实际上要求SIG查询仅定向到权威服务器，以避免这里可能引起的问题，并且在存在不理解SIG记录特殊属性的服务器时，这仍然是必要的。然而，在新实现中仔细设计SIG记录处理应该允许将来放宽此限制，因此解析器不需要特别对待SIG记录查询。

有时有人声称，收到的SIG记录请求应转发到权威服务器，而不是从缓存中的数据回答。这是不必要的——以这种方式具有SIG知识作为特殊情况进行处理的服务器将更好地正确缓存SIG记录，考虑到它们的特性。然后服务器可以确定何时可以安全地从缓存回复，以及何时答案不可用且必须转发查询。

5.3.2. NXT RRs (NXT资源记录)​

下一个资源记录（NXT）更为特殊。对于特定标签，区域中只会有一个NXT记录，因此从表面上看，RRSet问题是微不足道的。然而，在区域切割处，父区域和子区域（RFC2065术语中的超区域和子区域）将对同一名称具有NXT记录。这两个NXT记录不构成RRSet，即使两个区域都位于同一服务器上。NXT RRSet始终只包含单个RR。两个RRSet都可见的地方，存在两个RRSet。然而，服务器在接收响应中的NXT记录时不需要将其视为特殊情况。它们可以选择注意到存在两个不同的NXT RRSet，并像对待任何其他类型的两个不同RRSet一样对待它。也就是说，缓存一个，忽略另一个。安全感知服务器将需要正确处理接收到的响应中的NXT记录。

5.4. Receiving RRSets (接收RRSet)​

服务器绝不能将响应中的RR与其缓存中的RR合并以形成RRSet。如果响应包含的数据将与服务器缓存中的数据形成RRSet，则服务器必须忽略响应中的RR，或丢弃当前缓存中的整个RRSet，视情况而定。因此，缓存和响应之间的TTL变化问题不会引起关注，其中一个将被忽略。也就是说，如果来自答案的数据与缓存中的数据不同，则数据集之一总是不正确的。服务器面临的挑战是确定哪个数据集是正确的（如果有的话），并保留该数据集，同时忽略另一个。请注意，如果服务器收到包含与其缓存中相同的RRSet的答案，除了可能的TTL值之外，它可以选择使用接收到的答案的TTL更新其缓存中的TTL。如果接收到的答案被认为比先前缓存的答案更权威（如下一节所讨论的），则应该这样做。

5.4.1. Ranking data (数据排名)​

在考虑是否接受回复中的RRSet，或保留已在其缓存中的RRSet时，服务器应考虑各种数据的相对可能可信度。来自回复的权威答案应替换从早期回复中的附加信息获得的缓存数据。然而，如果缓存包含来自权威答案或区域文件的数据，则将忽略来自回复的附加信息。

假定可用数据的准确性来自其来源。可信度应按从最高到最低的顺序排列：

  • 来自主区域文件的数据，而不是胶水数据（glue data）
  • 来自区域传输的数据，而不是胶水
  • 权威回复的答案部分中包含的权威数据
  • 权威答案的权限部分的数据
  • 来自主区域的胶水，或来自区域传输的胶水
  • 来自非权威答案的答案部分的数据，以及来自权威答案的答案部分的非权威数据
  • 来自权威答案的附加信息
  • 来自非权威答案的权限部分的数据
  • 来自非权威答案的附加信息

请注意，权威答案的答案部分通常仅包含权威数据。然而，当查找的名称是别名时（参见第10.1.1节），只有描述该别名的记录必然是权威的。客户端应该假设其他记录可能来自服务器的缓存。在需要权威答案的地方，客户端应再次查询，使用与别名关联的规范名称。

从最不可信的那些分组接收和缓存的未经身份验证的RR，即来自附加数据部分的数据，以及来自非权威答案的权限部分的数据，不应以允许它们作为接收到的查询的答案返回的方式缓存。它们可以在适当的地方作为附加信息返回。忽略这一点将允许相对不可信数据的可信度在没有原因或借口的情况下增加。

当使用DNS安全[RFC2065]并且已收到并验证了经过身份验证的回复时，这样经过身份验证的数据应被视为比同一类型的未经身份验证的数据更可信。请注意，在本文档中，"权威"（authoritative）意味着设置了AA位的回复。DNSSEC使用受信任的SIG和KEY记录链来确定数据的真实性，AA位几乎无关紧要。然而，具有DNSSEC意识的服务器仍必须在响应中正确设置AA位，以使不具有安全意识的服务器能够正确运行（目前几乎所有服务器）。

请注意，除胶水外，来自两个正确配置的主区域文件、两个正确配置的辅助区域（来自区域传输的数据）或来自正确配置的主区域和辅助区域的数据不可能发生冲突。在多个区域中存在同一名称的胶水且值不同的地方，名称服务器应从主区域文件中选择数据优先于辅助区域，但否则可以选择任何单一的此类数据集。选择看起来来自更接近权威数据源的源在可以确定的地方可能是有意义的。选择主数据而不是辅助数据允许在存在此类数据问题时更容易发现错误胶水数据的来源。当服务器可以从两个区域文件中检测到一个或多个配置不正确，从而产生冲突时，它应该拒绝加载确定为错误的区域，并发出适当的诊断。

上面的"胶水"（Glue）包括区域文件中不是该区域的适当部分的任何记录，包括委派子区域的名称服务器记录（NS记录）、伴随这些NS记录的地址记录（A、AAAA等），以及可能出现的任何其他杂散数据。

5.5. Sending RRSets (reprise) (发送RRSet（重复）)​

资源记录集应该在任何DNS回复中只包含一次。它可能出现在答案、权限或附加信息部分中的任何一个，视需要而定。然而，它不应在同一个或任何其他部分重复，除非规范明确要求。例如，AXFR响应要求SOA记录（始终是包含单个RR的RRSet）既是回复的第一条记录也是最后一条记录。在以这种方式需要重复的地方，每种情况下传输的TTL必须相同。

Last updated on