The default behaviour for search domains changed from 16.10 to 17.04

I did some more tests. Using "dns-search=my.domain" and "ignore-auto-dns=true" actually works for wifi connections. For VPN (vpnc) is does not work.

The tool "systemd-resolve --status" still shows a tilda before the domain name ("DNS Domain: ~my.domain" instead of "DNS Domain: my.domain") and the name lookup for computers in my.domain does not work without giving the FQDN.

Kubuntu 17.04: openvpn

If “use this connection only for resources on its network” is checked, "systemd-resolve --status" shows "~" before the domain name as ThyMythos said.
And adding the correct domain on the options have not effect, only takes the domain pushed by vpn server prefixed with "~".

Status changed to 'Confirmed' because the bug affects multiple users.

Seems this lines of code are responsible:

src/dns/nm-dns-systemd-resolved.c:

static void
add_domain (GVariantBuilder *domains,
            const char *domain,
            gboolean never_default)
{
 /* If this link is never the default (e.g. only used for resources on this
  * network) add a routing domain. */
 g_variant_builder_add (domains, "(sb)", domain, never_default);
}

So someone actually wanted this behavious. The question is "why"? I definitly want to use my VPN only for resources on that network and yes I want to resolve the internal names of this network using a search domain.

This isssue is not relevant to VPN connections only but also for normal workin local network. systemd-resolve and systemd-resolved stub listener are behaving differently - the stub does not accept the domain/search domains sent by DHCP. THis is really weird. Isn't the issue in domain/search domains not properly put into a dynamic /etc/resolv.conf ?

Here are few examples (domain name change to fictive example.org):
1. Test of the Domain resolving using systemd-resolve:

$ systemd-resolve test
test: 192.168.0.53
      (test.example.org)

-- Information acquired via protocol DNS in 3.0ms.
-- Data is authenticated: no
sob@linno ~ $ nslookup test
Server: 127.0.0.53
Address: 127.0.0.53#53

** server can't find test: SERVFAIL

2. DNS resolve using the stub resolver:
$ nslookup - 127.0.0.53
> test
Server: 127.0.0.53
Address: 127.0.0.53#53

** server can't find test: SERVFAIL
> test.example.org
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: test.example.org
Address: 192.168.0.53
>

3. Example of /etc/resolv.conf
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

As a workaround you can do:

MY_DOMAIN="abc.org"
LINKS=`busctl tree --list org.freedesktop.resolve1 | grep link/_`
for L in $LINKS; do
        busctl get-property org.freedesktop.resolve1 $L org.freedesktop.resolve1.Link Domains \
        | grep -q $MY_DOMAIN \
        && sudo busctl call org.freedesktop.resolve1 $L org.freedesktop.resolve1.Link SetDomains "a(sb)" 1 "$MY_DOMAIN" "false"
done

I struggled with this long enough and took some notes about a workaround here: https://thealarmclocksixam.com/2017/08/08/dns-configuration-with-vpns-and-ubuntu-17-04-working-again/

I hope that this can help someone else as well.

I added search domains in '/etc/resolvconf/resolv.conf.d/base'. Now, I have at least named access to servers outside of our internal network.

Is there some checkbox in settings to enable searchdomains coming from dhcp?

PS: short domains also don't work. Only FQDNs.

> PS: short domains also don't work. Only FQDNs.

Fixed by changing:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

to

hosts: files mdns4_minimal [NOTFOUND=return] dns