- From: Howard Chu <hyc symas com>
- To: Jim Popovitch <yahoo jimpop com>
- Cc: networkmanager-list gnome org
- Subject: Re: dnsmasq
- Date: Fri, 26 Sep 2008 01:54:14 -0700
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.
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
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
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/
] [Thread Prev