[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: BIND will completely drop D-BUS dynamic forwarders table support



On Wed, 2007-12-05 at 16:04 -0500, Colin Walters wrote:
> On Wed, 2007-12-05 at 12:26 -0500, Bill Nottingham wrote:
> > > That's because it calls a magic function (res_init() or something) that
> > > means "really stat /etc/resolv.conf".  Bottom line is that currently on
> > > Linux, if your application wants to work on roaming wireless networks,
> > > you need to 
> > 
> > *stat*? Don't we have inotify these days?
> 
> I don't know whether an inotify-based approach would be accepted by the
> glibc maintainers.  Might be worth trying.  I have heard that glibc goes
> out of its way not to have any internal file descriptors, but inotify
> would require one.  I'm not sure how glibc would even use it without
> creating an internal thread or something.
> 
> I think the solution is going to be to require the OS to have a caching
> nameserver on localhost (i.e. /etc/resolv.conf is always 127.0.0.1), and
> for NetworkManager to control that nameserver in some way.  If BIND is
> dropping support for configuring itself (i.e. it doesn't want to be a
> usable caching nameserver for roaming laptops), then dnsmasq may be what
> we need to use.

The chaching nameserver is definitely the way to go imo.
It also would make it possible to do many other things like querying a
different name server based on the request.

For example I'd like to query my corporate domain server (over the vpn)
buy only for domain names that end in my.corp.com and use my ISP for
anything else.

This could *easily* be accomplished by a NM savvy caching name server
that get notified about dhcp/vpn parameters from network manager.

Simo.

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]