I think I am observing a regression caused by this fix: after
disconnecting/reconnecting a VPN connection, DNS resolution is broken.
Here are the details:
- VPN is set up as OpenVPN with split-tunneling ("Use this connection
only for resources on its network" is checked). The VPN's DNS domain is
ozone.caligrafix.cl, and the DNS server is 192.168.0.2. The local (non-
VPN) DNS server is 192.168.50.2.
- Right after boot, and after connecting to the VPN for the first time,
I can ping a host on the VPN's network (ping
somehost.ozone.caligrafix.cl)
- If I disconnect and reconnect to the VPN, I cannot ping the same host
by name (I get Name or service not known). I can ping it by IP.
Strangely enough, dnsmask says it does use the VPN's resolver, as shown
by this syslog extract:
Nov 1 23:09:28 tadzim3 dnsmasq[1671]: setting upstream servers from DBus
Nov 1 23:09:28 tadzim3 dnsmasq[1671]: using nameserver 192.168.50.2#53(via
wlan0)
Nov 1 23:09:28 tadzim3 dnsmasq[1671]: using nameserver 192.168.0.2#53 for
domain ozone.caligrafix.cl
Nov 1 23:09:28 tadzim3 dnsmasq[1671]: using nameserver 192.168.0.2#53 for
domain 1.8.10.in-addr.arpa
Nov 1 23:09:28 tadzim3 dnsmasq[1671]: using nameserver 192.168.0.2#53 for
domain 0.168.192.in-addr.arpa
Nov 1 23:09:28 tadzim3 dnsmasq[1450]: reading /etc/resolv.conf
Nov 1 23:09:28 tadzim3 dnsmasq[1450]: using nameserver 127.0.1.1#53
^C
gpothier@tadzim3:~$ ping somehost.ozone.caligrafix.cl
ping: somehost.ozone.caligrafix.cl: Name or service not known
--
You received this bug notification because you are a member of Desktop
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/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
