> \o/ Thanks again :)
> That is in most cases the *desired* behavior, On today's systems, I don't think so. Debian and Ubuntu run a dnsmasq instance by default, with the only nameserver in /etc/resolv.conf being 127.0.1.1. Rather than overwrite this local caching server with any remote one, it makes more sense to reconfigure *it* to include/remove the new nameservers. Not only can you continue to benefit from the cache, but it's smart enough to route lookups to different servers depending on the domain. That's a benefit because: > since only the VPN nameservers have name information about both the VPN and > the Internet. > Also, under what circumstances do you not trust the VPN with your DNS traffic? Well, if you work at home and connect to an employer's VPN, what earthly reason is there to send them all your Internet DNS lookups? It's far preferable to only use their nameservers just for employer.com and 99.10 .in-addr.arpa, or whatever. Not only that, but if you have a local nameserver that provides local names, you really don't want to wait for the remote to time out before querying those, either. That's exactly what NetworkManager does, simply by sending dnsmasq a DBus message with the new servers, and (optionally) what zones to use them for. However, it only works if the specific plugin in use is excluded from resolvconf's ppp/ip-up script. Come to think of it, there's a growing number of NM VPN plugins in the repos nowadays. There has to be a better way of handling this than excluding every one specifically... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1349011 Title: nm-l2tp-service needs exception in ppp ip-up/down scripts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1349011/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
