confused wiht the full resolver and stub resolver

[Chris Buxton]

On Nov 16, 2009, at 11:46 PM, aihua zhang wrote:

> HI,
>       Thanks for your help! Now I'm analysis the lib function providing by the bind . bind software has three data format:struct format, wire format and the text format, from my understanding, it presents the RR in different three types.in them text format is the string type storing in the db,   but i don't understand the wire format ,is that mean the data receive from the network and storing in the buffer ? and another question is struct format using environment is what ? 

This is mostly beyond my expertise, but I guess that wire format is the binary format used in the UDP packet. Struct format probably relates to the return value of the stub resolver library functions.

Chris Buxton
Professional Services
Men & Mice

> Best regards!
> 
> 2009/11/17 Chris Buxton <cbuxton at menandmice.com>
> 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
> 
> 
> 
> 
> -- 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20091117/f106d074/attachment.html>