[haiku-development] Re: Proposal: {dns,name,resolver}_server

> > > If the server handles the request, it would do whatever needed, 
> > > which 
> > > could end up calling libbind to actually resolve the address.
> > I was looking at ldns (http://www.nlnetlabs.nl/projects/ldns/) as the 
> > library to
> > use for the actual resolving. Really nice and clean API that has 
> > strong support
> > for generating and parsing DNS packets. I might even suggest that it 
> > be used instead
> > of libbind for system level DNS resolution (ie, telling the system to 
> > talk to the dns
> > part of net_server) once BeOS compatability goes away.
> 
> libbind isn't so bad either. Granted, its API isn't clean or nice, but 
> it's an established, and well maintained API. Furthermore, it's very 
> commonly available on other operating systems - keeping it around will 
> improve portability for little or no cost. Also, they care about binary 
> compatibility which allows us to actually export the API without 
> headaches.
> 
ldns is shiny though. :) But, Yeah the compatability is nice, though honestly
most people just go through the posix interface for resolution and never
actuallysee the innerworkings of libbind.

> > Still think the fallback isn't worth the trouble/complexity though. 
> > :) Basically means
> > we end up implementing DNS twice and not necessairly identically.
> 
> That's would indeed be the wrong way: libbind should be the only real 
> DNS resolver - it should be used by the net_server to do the real work, 
> and by the clients as a fallback mechanism. The net_server only extends 
> the capabilities, and provides caching. Things like Bonjour would end 
> up in the net_server, while smaller extensions could well be 
> implemented as part of libnetwork.so.
> 
Ok that makes sense. libbind will be augmented to read the new config and 
support
primary/secondary dns from that, while the dns extension in net_server will use
libbind to do more advanced resolution and caching.

alex

Other related posts: