This bug seems to bite me in a slightly different way. Please let me know if you feel that this is really a separate bug...
Also, this is happening on Yakkety - network-manager-1.2.4-0ubuntu1 When I connect to my work VPN, I'm not using split-tunnelling. Still the DNS resolution is split, causing DNS resolution to only be correct for my primary VPN search domain. This log snippet seems to explain it all: - 192.168.0.1 is my home ADSL DNS. - example.local is the search suffix provided by my VPN. - 10.10.10.12 and 10.10.10.13 are my VPN provided DNS servers. Oct 12 06:43:04 bar14860 NetworkManager[870]: <info> [1476261784.8455] dns-mgr: Writing DNS information to /sbin/resolvconf Oct 12 06:43:04 bar14860 dnsmasq[1226]: setting upstream servers from DBus Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 192.168.0.1#53(via enp0s31f6) Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 NetworkManager[870]: <info> [1476261784.9543] policy: set 'vpn0' (vpn0) as default for IPv4 routing and DNS The result of this is that all my other internal work-domains does not work at all, and may, as the bug describes, leak onto the internet as well. If you need more info, let me know. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1592721 Title: Don't write search domains to resolv.conf in the case of split DNS Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Released Bug description: [Impact] All VPN users meaning to use split-tunnelling in a situation where leaking DNS data to the internet about what might be behind their VPN is undesirable. [Test case] 1) connect to VPN 2) Use dig to request a name that should be on the VPN 3) Verify (kill -USR1 the dnsmasq binary from NM) that the request has only gone through the VPN nameservers (only its request number should have increased by one) 4) Use dig to request a name off-VPN, such as google.com. 5) Verify (kill -USR1 again) that the request has caused the non-VPN nameserver request number to increase, and that the VPN number has not increased. It is easier to verify this when there is as little traffic as possible on the system, to avoid spurious DNS requests which would make it harder to validate the counters. [Regression potential] This change modifies the way in which DNS nameservers and search domains are passed to dnsmasq, as such, if a VPN is configured in a non-standard way and intended to be used to resolve all network requests (which is typically not the case for split-tunnelling) or if the public network is intended to always resolve all requests while the VPN still provides search domains, one might observe incorrect behavior. Possible failure cases would include failure to resolve names correctly (resulting in NXDOMAIN or REFUSED from dnsmasq) or resolving to the incorrect values (if the wrong nameserver is used). --- Currently, NM will write all search domains to both any DNS-handling plugins running, and also to resolv.conf / resolvconf; in all cases. The issue is that doing so means that in the split-DNS case on VPNs, you might get a negative response from all nameservers, then a new request by glibc with the search tacked on, to nameservers again, which might cause DNS requests for "private" resources (say, on the VPN) to be sent to external, untrusted resolvers, or for DNS queries not meant for VPN nameservers to be sent through the VPN anyway. This is fixable in the case where we have a caching plugin running (such as dnsmasq). dnsmasq will already know about the search domains and use that to limit queries to the right nameservers when a VPN is running. Writing search domains to resolv.conf is unnecessary in this case. We should still write search domains if no caching gets done, as we then need to expect glibc to send requests as it otherwise would. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1592721/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp