Re: dnsmasq

[Dan Williams <dcbw redhat com>]

On Fri, 2008-09-26 at 00:04 -0400, Jim Popovitch wrote:
> On Thu, Sep 25, 2008 at 23:34, Howard Chu <hyc symas com> wrote:
> >> Perhaps it seems that way to you, but consider the case where someone
> >> might want DNS fixed (ie. to a local caching server that is configured
> >> to use opendns, 4.2.2.1, etc.) whilst using a wifi hotspot, but when
> >> in a tightly firewalled corporate environment they need to use the DNS
> >> servers specified by the site.    Also, multiple configuration options
> >> doesn't necessarily imply complexity, but rather flexibility.  More
> >> specific options are needed, not just general ones.
> >
> > You're completely missing the point:
> >
> >   You're either using a local caching server, or not. That's it, one simple
> > switch.
> 
> Correct.  However, the caching server needs to know what it's
> forwarders are..... and I would like those forwarders to vary based on
> connection or connection type.   Right now NM updates resolv.conf
> regardless of connection, so I have a manual step to update the
> forwarders.  If NM didn't update resolv.conf for certain connections,
> then I could do away with manual configuration for various
> connections.

NM 0.7 has supported custom DNS servers for a long time.  For each
connection you can specify exactly the DNS servers and search domains
you want to be used.  Thus for the Starbucks Wifi connection, you just
let DHCP provide your DNS, but when you connect to the VPN, the VPN's
DNS servers could either be from your VPN server or specified directly
by you.

Thus, were a caching nameserver used, NM would simply forward your
preferred DNS servers on a per-connection basis to the caching
nameserver.

> > All the variations you talk about are of course important, but those should
> > be handled in the caching DNS, not in resolv.conf. If you have a caching
> > DNS, resolv.conf should point to localhost, period, end of story.
> 
> Not necessarily.  I use a dhcp3 script to pull the forwarders out and
> update bind9 forwarders via an include + rndc reload.   That could go
> away if NM would allow a simple way of determining connection provided
> forwarders... such as a post-connection script call.

There is; dispatcher scripts have provided post-connection callouts
since NM 0.6.2 or something like that, way back in 2005.

> > As for myself, I don't ever operate without a local caching DNS. First it
> > makes most name lookups a lot faster, and second, I have mine configured to
> > point annoying domains like doubleclick.net and intellitxt.com at 0.0.0.0 so
> > that I'm never bothered by their junk when I'm browsing the web. Frankly I
> > don't think the Internet is usable today without explicit local control of
> > DNS resolution.
> 
> You really should be using 127.0.0.1 as 0.0.0.0 is an old broadcast
> addr.  I realize that *may* work for you, but.....
> 
> > None of the above is controlled by the settings in resolv.conf. When you're
> > at Starbucks, all of your DNS queries are intercepted by their system
> > anyway, so it doesn't matter what DNS servers you point to.
> 
> That's not my experience at T-Mobile enabled Starbucks, nor at
> hundreds of hotel/airport/cafe wifi locations.  It may be the case
> somewhere, but certainly not the norm.  Outbound DNS might be blocked,
> but re-routed... come on.

Most of the captive portals I've seen (airports, public libraries,
coffee shops, universities, Panera, etc) will capture your DNS requests
and redirect _all_ of them to the login page until you log in.  After
you log in, they may either forward them for you, or actually give you
upstream servers.  Though since many don't require a DHCP renew, they
probably forward your requests for you.

> > And the "domain"
> > and "search" directives in resolv.conf don't have anything to do with which
> > DNS servers you contact, it only controls what the resolver asks them when
> > you feed in a partially qualified name.
> 
> I don't use search and domain.... it would be great to have NM options
> to strip those out too.

Sure; just set the connection's IPv4 config method to "Automatic (DHCP)
addresses only" and just leave the search domains entry blank.

Dan

> >>> > The resolution rules in resolv.conf shouldn't depend on what network
> >>> > you're
> >>> > plugged into.
> >>
> >> I beg to differ.  You may not see the cases, but I do.   I routinely
> >> travel to diverse networking environments.  Sometimes I have a need to
> >> do lookups against VPN'ed servers, not customer de'jour's servers.
> >> Other times the network might be a testbed network with no DNS, but
> >> wide open access.  And finally there is the case of not utilizing a
> >> public wifi hotspot's DNS which is problematic, but rather using known
> >> (and secure) DNS servers like opendns.
> >
> > Again, the choice of DNS servers has nothing to do with the domain/search
> > resolution rules.
> 
> Sigh.  You really aren't getting my point.  I haven't cared about
> search or domain until you mentioned them above.  I only care about NM
> updating resov.conf.   I don't think a all or none solution (i.e.
> global) is reasonable, the user needs some level of control over which
> connections are allowed to update resolv.conf.
> 
> -Jim P.
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list