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

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 11 Nov 2009 10:42:15 +0100

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.
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.
If the server handles the request, it would do whatever needed, which 
could end up calling libbind to actually resolve the address.

[...]
> > Basically, libbind would try to forward the calls to the net_server 
> > - 
> > if that one isn't running, it would fall back to the default 
> > resolver.
> Where does the default resolver get stored? Hopefully not resolv.
> conf, I think that
> just leads to confusion like the OS X case, where DNS is configured 
> for different apps
> in different places.

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

Bye,
   Axel.

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 11-2009