Re: dnsmasq



Jim Popovitch wrote:
On Fri, Sep 26, 2008 at 02:59, Howard Chu<hyc symas com>  wrote:
Hm. So what exactly did you mean by saying "the user needs some level of
control over which connections are allowed to update resolv.conf" ?

Certainly not control of packet routing.  All I meant by that
statement, and it's hard for me to imagine you can see it any other
way, is that NM users need a level of control over which connections
touch resolv.conf.   If you recall, prior to that single statement you
quoted, I had suggested three options (global, connection, connection
type).   None of that implies anything close to the left field you
have drug this thread into.

Yes, it's a good idea to have control over how nameserver info received from
various interfaces gets used by the local machine. But trying to slot any of
those controls into /etc/resolv.conf is futile.

<sigh>   You really don't understand the issue myself and others have
pressed for.

No. It seems I understand it better than you.

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.

Obviously I agree that you should be able to decide which connections' nameserver info is allowed to be used. But implementing that control by deciding whether they can or cannot update resolv.conf is the wrong way to do it. Now if you were to decouple "allow connection's info to be used" from "update resolv.conf" and allow for other actions to be taken instead, then you'd have something.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


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