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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 12 Nov 2009 09:47:16 +0100

Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx> wrote:
> > The client would first ask the server, but if that isn't available 
> > it 
> > would just continue to do what it's currently doing. This requires 
> > that 
> > libbind and the server are understanding/using the same 
> > configuration 
> > files.
> I really feel like the fallback mechanism to using libbind directly 
> is just
> not worth the trouble. It means any of the advanced features need to 
> be
> implemented in libbind or create a confusing situation where the dns 
> part of
> net_server stops responding and for some reason dns lookups work, but 
> not
> quite as you'd expect. I'd rather it be totally broken then partially 
> broken.

net_server should only provide optional services. DNS in general is not 
an optional service at all. I think it's okay to augment the DNS 
functionality when net_server is running - usually, it will run, and it 
will be your conscious decision not to run it if you want to (but it's 
obvious that you would then lose some functionality).

> > 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 

Apart from that, libbind would also only be needed for BeOS BONE 
compatibility - BeOS R5 never had it. So it's not that we couldn't drop 
it if we wanted to. I just don't see any reason to do so.

> > Currently, there is only /boot/common/settings/network/resolv.conf. 
> > You 
> > could extend this to your needs (and adapt libbind to cope with 
> > it), or 
> > replace it with your own (preferably driver settings compatible), 
> > and 
> > adapt libbind to cope with it, too :-)
> Yes I'd probably try and fit the DNS information into the driver 
> settings rather then
> use resolv.conf.
> 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.


Other related posts: