7. Stub Resolver Considerations

   Although not strictly required to do so by the protocol, most DNS
   queries originate from stub resolvers.  Stub resolvers, by
   definition, are minimal DNS resolvers that use recursive query mode
   to offload most of the work of DNS resolution to a recursive name
   server.  Given the widespread use of stub resolvers, the DNSSEC

   architecture has to take stub resolvers into account, but the
   security features needed in a stub resolver differ in some respects
   from those needed in a security-aware iterative resolver.

   Even a security-oblivious stub resolver may benefit from DNSSEC if
   the recursive name servers it uses are security-aware, but for the
   stub resolver to place any real reliance on DNSSEC services, the stub
   resolver must trust both the recursive name servers in question and
   the communication channels between itself and those name servers.
   The first of these issues is a local policy issue: in essence, a
   security-oblivious stub resolver has no choice but to place itself at
   the mercy of the recursive name servers that it uses, as it does not
   perform DNSSEC validity checks on its own.  The second issue requires
   some kind of channel security mechanism; proper use of DNS
   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
   Particular implementations may have other choices available, such as
   operating system specific interprocess communication mechanisms.
   Confidentiality is not needed for this channel, but data integrity
   and message authentication are.

   A security-aware stub resolver that does trust both its recursive
   name servers and its communication channel to them may choose to
   examine the setting of the Authenticated Data (AD) bit in the message
   header of the response messages it receives.  The stub resolver can
   use this flag bit as a hint to find out whether the recursive name
   server was able to validate signatures for all of the data in the
   Answer and Authority sections of the response.

   There is one more step that a security-aware stub resolver can take
   if, for whatever reason, it is not able to establish a useful trust
   relationship with the recursive name servers that it uses: it can
   perform its own signature validation by setting the Checking Disabled
   (CD) bit in its query messages.  A validating stub resolver is thus
   able to treat the DNSSEC signatures as trust relationships between
   the zone administrators and the stub resolver itself.