On Thu, Sep 25, 2008 at 23:34, Howard Chu <[EMAIL PROTECTED]> 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. > 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. > 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. > 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. >>> > 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 [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
