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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
