[Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS

[Thomas M Steenholdt]

@Vincent, re the "If lookups are routed to multiple interfaces, the
first successful response is returned", this is indeed the problem with
systemd-resolved as I see it, as that method will never be stable for a
split DNS setup... You can never reliably predict if you'll get a good
or a bad IP for the connections you're currently using.

dnsmasq allows a solution to this, because NetworkManager can tell
dnsmasq to use the LAN DNS for default stuff, but use the VPN DNS for
lookups in the example.lan domain and 10.in-addr.arpa, for example.

The dhcp-options you mention is for a direct call to openvpn if I'm not
mistaken(?). That would work if you're content with launching every VPN
connection by hand. In my case, I use a bunch of different VPN clients
and as such, solving this in NetworkManager is a much more universally
applicable fix.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1624317

Title:
  systemd-resolved breaks VPN with split-horizon DNS

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I use a VPN configured with network-manager-openconnect-gnome in which
  a split-horizon DNS setup assigns different addresses to some names
  inside the remote network than the addresses seen for those names from
  outside the remote network.  However, systemd-resolved often decides
  to ignore the VPN’s DNS servers and use the local network’s DNS
  servers to resolve names (whether in the remote domain or not),
  breaking the split-horizon DNS.

  This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL:
  https://bugzilla.redhat.com/show_bug.cgi?id=1151544

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions