GNOME Bugzilla – Bug 782469
Search domains are not considered for split-tunnelling connections
Last modified: 2020-11-12 14:34:22 UTC
For split-tunnelling VPN connections (i.e. when the "Use only for resources on this connection" checkbox is set in the IPv4 -> Routes menu), the IPv4 -> Search Domains field has no effect. For example, my VPN connection has the following parameters: [ipv4] dns=xxx.xxx.xxx.xxx; dns-search=mydomain.net; ignore-auto-dns=true method=auto never-default=true After connecting, `systemd-resolve --status` shows for this connection: Link 5 (tun0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: allow-downgrade DNSSEC supported: yes DNS Servers: xxx.xxx.xxx.xxx DNS Domain: ~mydomain.net Note that there is a ~ character before the domain name, which has a special semantics in systemd-resolved (as I understand, such entries are not used as search names). As a result, the search name is not used to complete simple names: systemd-resolve foo foo: resolve call failed: All attempts to contact name servers or networks failed ping foo ping: foo: Name or service not known ping foo.mydomain.net 64 bytes from xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=62 time=5.33 ms Note that the search domains work if the VPN connection is configured as non-split-tunnelling connection. In this case `systemd-resolve --status` shows "DNS Domain: mydomain.net" (without ~) and `systemd-resolve foo` and `ping foo` work as expected. I'm using Kubuntu 17.04, x86_64, NetworkManager 1.4.4.
*** Bug 783024 has been marked as a duplicate of this bug. ***
(In reply to Beniamino Galvani from comment #1) > *** Bug 783024 has been marked as a duplicate of this bug. *** I'm not sure this is a direct duplicate. This bug clearly sets the "dns-search" in the NM connection config file. (I don't see a way to set it in the UI, but that's a different issue). In my bug, it is about using the value provided via DHCP. The end product is the same, but it seems likely two different places in code.
(In reply to Pat Suwalski from comment #2) > (In reply to Beniamino Galvani from comment #1) > > *** Bug 783024 has been marked as a duplicate of this bug. *** > > I'm not sure this is a direct duplicate. > > This bug clearly sets the "dns-search" in the NM connection config file. (I > don't see a way to set it in the UI, but that's a different issue). > > In my bug, it is about using the value provided via DHCP. > > The end product is the same, but it seems likely two different places in > code. The root cause is the same, i.e. that NM pushes the domains to systemd-resolved as routing-only if the VPN doesn't get the default route. The place where this happens in the code is here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns/nm-dns-systemd-resolved.c?id=31656a066bfb3edc106f5efd5d2be46396824930#n208 for both cases. I think the NM backend for systemd-resolved should be changed to behave like the dnsmasq one.
I'd like to add that I tried the same settings with dnsmasq instead of systemd-resolved and it doesn't work either (i.e. the search domain is not used to complete simple names when the VPN connection is established). I can't tell if this is the same or a separate issue.
6 months passed and is anyone looking into this? Definitely, dnsmasq does not work this way. Short DNS names are resolved just fine with split DNS settings there. "Don't get default route" setting has nothing to do with DNS semantically. I just want VPN not to be used for everything but local short DNS names shall continue to resolve properly. I would suggest just stop adding "route_only" domains until a better solution is designed. Lots of people on the latest Ubuntu releases (which made systemd-resolve default) are hit by this problem: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1684854
(1.10.10) I think I'm stuck with the same thing. Expectation was that `[global-dns] searches=mydomain.net` would simply solve this, but this key seems to be completely ignored, too.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).