我注意到我的安全意识parsing器有一个奇怪的行为。
parsing安全域名时，parsing器会收到DS RRset和NS RRset。 但是当它处理到数据的validation时，它会再次请求DS RRset。
它似乎没有caching它得到的第一个。
我不知道我是否清楚，让我们来看看www.example.com. IN A ?会发生什么www.example.com. IN A ? www.example.com. IN A ? 。 请注意，我随机select此域名并不代表真实域名，如果此域名受DNSSEC保护，则不会进行事件检查。
首先，parsing器将parsing域名：
[...] #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)
好的，现在parsing器有答案，但需要进行validation。
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足够大）
从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.