confused wiht the full resolver and stub resolver

[Chris Buxton]

On Nov 15, 2009, at 11:35 PM, aihua zhang wrote:

> HI, 
>       here is my understanding about the stub resolver and full resolver:
>          stub resolver,used by client and independent name server. application will call the routine of the lwreslib(such as lwres_getrdatabyname()) and the lwresd will handle the request using the lightweight protcol. when lwresd received the request it will render it and  send it to the name server listed in the resolv.conf. here is my confused:
>           1. I find the helper document written:"the full resolver is part of the caching name server or reolver demon the stub resolver talks to " ,  can i unstand  all request from the stub resolver handled by  the full resolver in the name server . if not which module handle this kind request
>           2. if the request tackle by the full resolver , the client.h of the named module handle which type?

The job of the stub resolver is to be a DNS client. Applications on
client machines use the stub resolver, typically (part of) a dynamic
library of some sort, to interface with the DNS as well as other name
resolution systems, such as /etc/hosts.

The stub resolver in BIND 9 is, I believe, somehow based on or
intertwined with lwresd. However, it is not the only stub resolver
implementation out there.

The job of the full resolver is to recurse through the DNS name
hierarchy in response to requests. It is almost always a service that
gets requests via the DNS protocol. For example, the BIND 9 name server
can act as a full resolver, when configured as a caching name server.
However, it's perfectly possible (but highly unusual) for the (full)
resolver to replace the stub resolver, taking requests from clients via
a library function call and doing its own recursion.

The typical resolution process works like this:

1. An application invokes the stub resolver as function call, from a
   library.
2. The stub resolver, possibly after consulting /etc/hosts, ldap, nis+,
   etc., sends a recursive DNS query to a DNS server via the network.
   If necessary, the stub resolver will retransmit the query, query
   another DNS server, etc., until either it gets an answer or gives up.
3. The DNS server, acting as a full resolver (a caching name server),
   consults its cache and then, if necessary, performs recursion (asks
   other name servers, traversing the DNS name hierarchy) in order to
   find the answer.
4. The caching name server (full resolver) sends an answer back to the
   stub resolver in the form of a DNS message.
5. The stub resolver function returns a data structure to the
   application.

However, again, this is only the most typical procedure. Variations are
quite possible, including removing the stub resolver entirely.

Chris Buxton
Professional Services
Men & Mice