confused wiht the full resolver and stub resolver

2009-11-15 Thread aihua zhang
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?




-- 
Best regards!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: confused wiht the full resolver and stub resolver

2009-11-16 Thread 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

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: confused wiht the full resolver and stub resolver

2009-11-17 Thread 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 
> 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

Re: confused wiht the full resolver and stub resolver

2009-11-17 Thread Mark Andrews

In message <396ef6ed-a5a2-4c55-afd4-496b85278...@menandmice.com>, Chris Buxton 
writes:
> 
> 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

The text format is what is in master files and is what dig displays.
This is standardized.

The wire format is what is sent between machines.  This is also how
named and libdns store records internally with all compression
pointers expanded.  This is standardized.

The struct format is a way to break down individual records into
their components if they are known.  This is useful for C programs
that need to examine specific fields.  This is not standardized.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users