My resolver doesnt cache the DS RR sent with NS RR

Question

I noticed a strange behaviour on my security-aware resolver.

When resolving a secured domain name, the resolver receives DS RRset along with NS RRset. But when it processes to the validation of the data, it asks for for DS RRset again.

It seems it doesn't cache the first one it got.

I don't know if I'm very clear, let's look what happens with www.example.com. IN A ?. Note that I choose this domain name randomly and does not represent the real one, I didn't event checked if this domain was DNSSEC-secured.

First, the resolver will resolve the domain name:

[...] #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)

Okay, so now, the resolver has the answer, but need to autenticate it.

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 "[...]"

What's the point of asking something it already got? (TTL are big enough)

score 0 · Accepted Answer · edited Oct 07 '21 at 08:14

From 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.

Each RRset should be cached as a single atomic entity. In other words, components should not be reused. Caching all of the individual components would place unreasonable restrictions on answers that are obtained after any of the component RRs have been updated. (i.e. they would fail validation)
If any of the TTLs in the RRset expire, the entire RRset should be expired.

I read that section, but didn't though it was the cause of my trouble. I still wonder why the nameserver sent these informations if it can't be used. Maybe you could add this to your answer?! — Dan928, Jun 08 '15 at 07:16
If you can clarify very specifically which records you think are being requested needlessly I might be able to explain further. — Andrew B, Jun 08 '15 at 13:54

My resolver doesnt cache the DS RR sent with NS RR

1 Answers1