Comment 119 for bug 1624317

After issuing the systemd-resolved API method/bus call SetLinkDomains(5 (the if_index of the vpn con-id 'tun0' in this case), ".", TRUE), the output of systemd-resolve --status for the vpn con-id 'tun0' looks like this:

Link 5 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 209.222.18.222
                      209.222.18.218
          DNS Domain: ~.

and there are no DNS leaks, as the routing-only domain is used.

**********
From SYSTEMD.NETWORK(5):

"The "routing-only" domain "~." (the tilde indicating definition of a routing domain, the dot referring to the DNS root domain which is the implied suffix of all valid DNS names) has special effect. It causes all DNS traffic which does not match another configured domain routing entry to be routed to DNS servers specified for this interface. This setting is useful to prefer a certain set of DNS servers if a link on which they are connected is available.

This setting is read by systemd-resolved.service(8). "Search domains" correspond to the domain and search entries in resolv.conf(5). Domain name routing has no equivalent in the traditional glibc API, which has no concept of domain name servers limited to a specific link."

**********
So the problem here is that when using network-manager-openvpn/network-manager-openvpn-gnome through the network-manager, there is no option to specify the routing-only domain, and even manually specifying the DNS servers and entering "." or "~." under "Edit Connections"->"<VPN Connection Name>"->"IPv4 Settings"->"Method=Automatic (VPN) addresses only"->"Search Domains" has no effect (i.e. the routing-only domain is not set).

Then we have a problem where DNS queries leak by design of systemd-resolved. But fortunately, also by design, we can choose to use the'routing-only domain', which solves the problem of DNS leaks using systemd-resolved. But the network-manager does not seem to be able to issue this call for some reason, perhaps because it views "." or "~." as invalid 'Search Domains' and doesn't parse or send that information correctly to nm-systemd-resolved.c.

So...my patch is basically a stopgap measure to force the network-manager to make the bus call for the routing-only domain on a VPN connection. However, this may not be desired for all VPN connections, so obviously it's not optimal. There needs to be a change here where we can manually specify the routing-only domain for a VPN connection to prevent DNS leaks.

I think a lot of confusion on the launchpad thread is the fact that many bugs were marked duplicates of something that is actually two separate issues. Split-horizon DNS setups with openconnect are fundamentally different from DNS leaks over a 'total internet' VPN provider through which all domain-names are resolved like 'Private Internet Access' (or any number of privacy-focused VPN service providers), which I'm using through network-manager-openvpn.