BIND will completely drop D-BUS dynamic forwarders table support

[Dan Williams]

On Fri, 2007-12-07 at 11:42 +0100, Adam Tkac wrote:
> On Thu, Dec 06, 2007 at 06:11:48PM -0600, Callum Lerwick wrote:
> > 
> > On Thu, 2007-12-06 at 07:25 -0600, Jima wrote:
> > > On Wed, 5 Dec 2007, Callum Lerwick wrote:
> > > > This is *exactly* what dnsmasq is designed for. From what I can tell, 
> > > > the author added dbus support to dnsmasq *specifically* so 
> > > > NetworkManager could use it. I'm not sure what's up with the disconnect 
> > > > here. :)
> > > 
> > >   Maybe not NM specifically, but certainly conceptually:
> > > 
> > > "Added method support for DBus (http://www.freedesktop.org/Software/dbus)
> > > This is a superior way to re-configure dnsmasq on-the-fly with different 
> > > upstream nameservers, as the host moves between networks. DBus support 
> > > must be enabled in src/config.h and should be considered experimental at 
> > > this point. See DBus-interface for the specification of the DBus method 
> > > calls supported."
> > 
> > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00023.html
> > http://osdir.com/ml/network.networkmanager.devel/2005-05/msg00012.html
> > http://osdir.com/ml/network.networkmanager.devel/2005-04/msg00036.html
> > 
> > The dnsmasq author was very eager to have dnsmasq used by NM back in
> > 2005. I haven't found any explanation as to why it didn't happen.
> > 
> > Here's a nice fresh thread, it even links back to this one:
> > 
> > http://www.nabble.com/nm-with-dnsmasq--t4940689.html
> > 
> > They seem really dead set on sticking with bind. Seriously, why?
> 
> Why? Generally dnsmasq (or other lightweight) DNS server beat BIND
> with executable size and performance on one processor systems. In
> other cases like functionality, performance on multi cores and
> portability beat BIND other servers. And as I wrote above future of
> DNS is in DNSSEC. And I'm not sure if dnsmasq author is eager to
> implement it. That's why BIND should not be marked as irrelevant on this
> field.

NM shouldn't really care what the caching nameserver implementation is,
anything is fine.  It just happens that the current bits talked to named
because patches for dnsmasq didn't materialize out of thin air.  Plus
I'd like to rethink how NM interacts with nameservers (ideally, NM waits
for pulls, not pushes stuff out).

But that shouldn't stop somebody from writing a patch for pushing info
to dnsmasq that works today, if dnsmasq's dbus name is claimed on the
system bus.  If both named and dnsmasq are claimed, then NM should just
pick one (dnsmasq perhaps).  If neither name is claimed, NM should fall
back to the current behavior of writing out resolv.conf directly.

Dan