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

  • From: Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx, "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • Date: Wed, 11 Nov 2009 11:15:18 -0800

> Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx> wrote:
> > > Something like this (for caching, mostly, but also for things like 
> > > Bonjour/ZeroConf) is already the plan. However, it should be made 
> > > part 
> > > of the net_server, and not be an extra server.
> > Awesome. Good to know I wasn't totally out-of-bounds. :) I was also 
> > looking
> > at multicast dns, but figured I'd start with something simple and go 
> > from there.
> > For now I will just aim to get the basics: a server that forwards to 
> > the primary
> > and then secondary DNS as set by DHCPClient or the preflet.
> 
> Just to make sure I did not misunderstand you:
> My plan was to add a BLooper to net_server that is responsible for 
> resolving DNS queries.
I must admit my plan was to actually have this be a real DNS server (reading
requests on UDP 53 and responding with well-formed DNS requests). It seems
like it makes the bridge between some resolving library that things like
gethostbyname() are implemented with and the DNS support in net_server.

I could go this route instead: having messages like ResolveHostname and 
responding
to them and then having libbind (or something like it) talk that bmessage 
protocol instead.

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

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

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


Alex

Other related posts: