Re: dnsmasq

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. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

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