我的解析器没有缓存随 NS RR 一起发送的 DS RR

我的解析器没有缓存随 NS RR 一起发送的 DS RR

我注意到我的安全感知解析器出现了奇怪的行为。

在解析安全域名时,解析器会收到 DS RRset 和 NS RRset。但当它处理数据验证时,它会再次请求 DS RRset。

看来它没有缓存它得到的第一个。


我不知道我是否说得很清楚,让我们看看会发生什么www.example.com. IN A ?。请注意,我随机选择了这个域名,才不是代表真实的,我甚至没有检查该域是否受 DNSSEC 保护。

首先,解析器会解析域名:

[...] #Asks NS "." and gets com. NS

Resolver  -> NS "com."
Qry:  www.example.com.   IN    A     ?

NS "com." -> Resolver
Qry:  www.example.com.   IN   A      ?
Auth: example.com.       IN   NS     ns.example.com.
      example.com.       IN   DS
      example.com.       IN   RRSIG  (DS)
Add:  ns.example.com.    IN   A      IP_NS.EXAMPLE.COM


Resolver          -> NS "example.com."
Qry:  www.example.com.   IN   A      ?

NS "example.com." -> Resolver
Qry:  www.example.com.   IN   A      ?
Ans:  www.example.com.   IN   A      IP_WWW.EXAMPLE.COM.
      www.example.com.   IN   RRSIG  (A)
Auth: example.com.       IN   NS     ns.example.com.
      example.com.       IN   RRSIG  (NS)
Add:  ns.example.com.    IN   A      IP_EXAMPLE.COM
      ns.example.com.    IN   RRSIG  (A)

好的,现在解析器有了答案,但需要对其进行验证。

Resolver          -> NS "example.com."
Qry:  example.com.       IN   DNSKEY ?

NS "example.com." -> Resolver
Qry:  example.com.       IN   DNSKEY ?
Ans:  example.com.       IN   DNSKEY (KSK_current)
      example.com.       IN   DNSKEY (ZSK_current)
      example.com.       IN   DNSKEY (ZSK_published)
      example.com.       IN   RRSIG  (KSK_current)
      example.com.       IN   RRSIG  (ZSK_current)


Resolver  -> NS "com."
Qry:  example.com.       IN   DS    ?

NS "com." -> Resolver
Qry:  example.com.       IN   DS    ?
Auth: example.com.       IN   NS     ns.example.com.
      example.com.       IN   DS
      example.com.       IN   RRSIG  (DS)
Add:  ns.example.com.    IN   A      IP_EXAMPLE.COM

[...] #Does the same thing with "com. DS ?", but it got it in previous skipped part "[...]"

询问已经得到的东西有什么意义?(TTL 足够大)

答案1

RFC-4035 §4.5

4.5.  Response Caching

   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named RRset
   and any associated DNSSEC RRs.  The resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.  In
   most cases the appropriate cache index for the atomic entry will be
   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
   form described in Section 3.1.3.2 the appropriate cache index will be
   the double <QNAME,QCLASS>.

   The reason for these recommendations is that, between the initial
   query and the expiration of the data from the cache, the
   authoritative data might have been changed (for example, via dynamic
   update).

   There are two situations for which this is relevant:

   1.  By using the RRSIG record, it is possible to deduce that an
       answer was synthesized from a wildcard.  A security-aware
       recursive name server could store this wildcard data and use it
       to generate positive responses to queries other than the name for
       which the original answer was first received.

   2.  NSEC RRs received to prove the non-existence of a name could be
       reused by a security-aware resolver to prove the non-existence of
       any name in the name range it spans.

   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.
  • 每个 RRset 都应作为单个原子实体进行缓存。换句话说,组件不应重复使用。缓存所有单个组件会对任何组件 RR 更新后获得的答案施加不合理的限制。(即它们将无法通过验证)
  • 如果 RRset 中的任何 TTL 过期,则整个 RRset 也应该过期。

相关内容