Я заметил странное поведение моего распознающего устройства с учетом безопасности.
При разрешении защищенного доменного имени преобразователь получает 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 достаточно большие)
Из 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.