Re: confused wiht the full resolver and stub resolver
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 cbux...@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 -- ___ 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
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
Re: confused wiht the full resolver and stub resolver
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
confused wiht the full resolver and stub resolver
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
