Re: dnsmasq

[Howard Chu <hyc symas com>]

Jim Popovitch wrote:
> On Fri, Sep 26, 2008 at 03:29, Howard Chu<hyc symas com>  wrote:
> > The point is that users need a level of control over how name resolution is
> > done. Once you resort to adding/removing entries from resolv.conf you've
> > completely removed the possibility of retaining local control over name
> > resolution. If you leave /etc/resolv.conf pointed at your local caching name
> > server, you retain full control. You can make local policy decisions about
> > how to handle any particular name lookup, instead of just blindly walking
> > down a list of 3 server addresses in a flat file for all lookups.
>
> See, there you go again.  Injecting a perceived feature request that
> no one in this thread has requested.  You really must come back to
> ground level and understand that NO ONE is asking you or NM for
> fine-grained name resolution control.  Nope, no one.

Then you're either inexperienced or short-sighted and haven't thought it 
through all the way.

> The only
> feature requested was for NM to provide a checkbox style boolean
> option to enable/disable resolv.conf updating (a'la DNSUpdate in Cisco
> VPNs) in NM Global options, individual connection settings, and
> (possibly) as an option per connection type (i.e. wired/wireless).
> NOTHING MORE.  No need to try and push people to use dnsmasq, no need
> to espouse your great knowledge of all things, no need for you to
> educate anyone.   In fact, a simple "Yes it can be done" or "No,
> that's impossible to implement" would have sufficed.

It's only software, anything can be done. But is it worth doing, will it be 
useful in the real world?

The options you requested will add a degree of complexity to the configuration 
but will not add a commensurate degree of usability. Back to your original 
example:

> For instance, I might want to normally use my local caching
> nameserver, but if using wired (at HQ) I might want NM to update
> resolv.conf so that I can resolve corp devices/systems.

The right thing to do here is to add the corp nameservers to the local cache's 
forwarders. Particularly if your local caching nameserver has already been 
configured with a lot of other local customizations. Bypassing your local 
cache would be one of the most unfriendly things you could do.

> VPN plugins need a "don't touch resolv.conf" option too!

That just makes life harder. If the VPN provides a list of nameservers, those 
servers are most likely serving names for addresses within the private 
network, names for hosts that you wanted to work with (otherwise why are you 
using the VPN in the first place?). If you want to be able to use hosts on 
that network by name, then you want the nameservers to be made available to 
your machine. But, you also want those nameservers to be used only when 
necessary, only for the relevant domains. Simply omitting the nameservers from 
resolv.conf forces you to use hosts files or numeric addresses to get your 
work done. Simply adding them to resolv.conf means they'll be fair game for 
answering arbitrary queries, which will at least slow down system throughput, 
and at worst return erroneous NXDOMAIN results depending on how they're 
configured.

Having been in both of the above situations many times, I can say that a 
simple on-off toggle for allowing these connections to update resolv.conf 
wouldn't have improved the usability of the system a single bit.

Moreover, there is no "simple on-off toggle" - for the first example, there's 
no handy name like a WiFi SSID to associate with a wired network. So you have 
to configure a domain name and/or a subnet address with the connection type, 
and subnet address is error-prone if your desired corp network just uses 
192.168 or some other private network address.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/