Вопросы Теги

Мой сопоставитель не кэширует RR DS, отправленный с NS 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
задан 5 June 2015 в 11:42
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 компонента. (т.е. они не пройдут валидацию)
  • Если истечет любой из TTL в RRset, истечет весь RRset.
0
ответ дан 4 December 2019 в 07:34

Теги

Похожие вопросы