6. Resolver Considerations

   A security-aware resolver has to be able to perform cryptographic
   functions necessary to verify digital signatures using at least the
   mandatory-to-implement algorithm(s).  Security-aware resolvers must
   also be capable of forming an authentication chain from a newly
   learned zone back to an authentication key, as described above.  This
   process might require additional queries to intermediate DNS zones to

   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
   resolver should be configured with at least one trust anchor as the
   starting point from which it will attempt to establish authentication
   chains.

   If a security-aware resolver is separated from the relevant
   authoritative name servers by a recursive name server or by any sort
   of intermediary device that acts as a proxy for DNS, and if the
   recursive name server or intermediary device is not security-aware,
   the security-aware resolver may not be capable of operating in a
   secure mode.  For example, if a security-aware resolver's packets are
   routed through a network address translation (NAT) device that
   includes a DNS proxy that is not security-aware, the security-aware
   resolver may find it difficult or impossible to obtain or validate
   signed DNS data.  The security-aware resolver may have a particularly
   difficult time obtaining DS RRs in such a case, as DS RRs do not
   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
   that this problem is not specific to NATs: any security-oblivious DNS
   software of any kind between the security-aware resolver and the
   authoritative name servers will interfere with DNSSEC.

   If a security-aware resolver must rely on an unsigned zone or a name
   server that is not security aware, the resolver may not be able to
   validate DNS responses and will need a local policy on whether to
   accept unverified responses.

   A security-aware resolver should take a signature's validation period
   into consideration when determining the TTL of data in its cache, to
   avoid caching signed data beyond the validity period of the
   signature.  However, it should also allow for the possibility that
   the security-aware resolver's own clock is wrong.  Thus, a
   security-aware resolver that is part of a security-aware recursive
   name server will have to pay careful attention to the DNSSEC
   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
   blocking valid signatures from getting through to other
   security-aware resolvers that are clients of this recursive name
   server.  See [RFC4035] for how a secure recursive server handles
   queries with the CD bit set.