© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
I hit this too; my company uses Juniper's NetworkConnect and it adds its own DNS servers as the first ones to search to /etc/resolv.conf. I disabled the download of the DNS server info altogether which is obviously not optimal, but works OK for me because I've installed a Linux image on my Linksys router and enabled dnsmasq, so my local LAN DNS server is always my router, which never changes, not my upstream ISP. But, when I configured a laptop for a friend they have this problem in spades.
To me, anything that watches for changes to /etc/resolv.conf and tries to change things back again is just not reliable enough. Ditto for having scripts depending on seeing a tun0 or ppp0 or whatever interface.
I think the right answer HAS to be a smarter dhclient script. It's the only one that seems reliable and robust. An easy answer that will help most of the time was already suggested: if the hostname to be added to resolv.conf already exists, then don't change resolv.conf. This seems like something that is obviously correct and won't cause any problems.
This works for me because my VPN solution leaves the original nameserver entry in /etc/resolv.conf, it's just put at the bottom. I suppose some people might have problems if their VPN solution completely replaces /etc/resolv.conf. That might require a more sophisticated solution.