Please retest with systemd-217. There were various fixes post 215.

Commit 87f5a19343acf8ba697acc5a62bdb1a2b8c9eda3 should fix the duplicate servers at least.

That's going to have to wait a while, as this is my work machine and I don't feel comfortable recompiling PID1 on that. I'll see if Debian can provide a newer version in experimental, but I suspect the maintainers have other priorities right now, given Debian's release freeze.

Using current git HEAD, -networkd is still not writing out any domain search lists into its leases file. Starting systemd-resolved fails to start entirely with no errors logged, but starting it manually (as root) gives the following error messages:

Using system hostname '$(hostname)'.
Failed to register name: Permission denied
Could not create manager: Permission denied

All releases after 215 have this same behaviour. Note that I tested this with 215 still running as PID1, I did not replace any of the binaries on the system except for the -networkd and -resolved daemons. That may be why newer -resolved versions failed to start, but that is not obvious to me from the output.

(In reply to Arno Schuring from comment #3)
> Starting systemd-resolved fails to start entirely with no errors logged

For clarity, I meant "starting systemd-resolved as a service", i.e. installing the newly compiled binary over the original one in /lib/systemd, then issuing systemctl start systemd-resolved.

(In reply to Arno Schuring from comment #3)

> entirely with no errors logged, but starting it manually (as root) gives the
> following error messages:
> 
> Using system hostname '$(hostname)'.
> Failed to register name: Permission denied
> Could not create manager: Permission denied
> 
> All releases after 215 have this same behaviour. Note that I tested this
> with 215 still running as PID1, I did not replace any of the binaries on the
> system except for the -networkd and -resolved daemons. That may be why newer
> -resolved versions failed to start, but that is not obvious to me from the
> output.

You need to install the dbus policy file for resolved as well, the binary alone won't be enough.

(In reply to Lennart Poettering from comment #5)
>
> You need to install the dbus policy file for resolved as well, the binary
> alone won't be enough.

Thanks, that helps. With that change (copying src/resolve/org.freedesktop.resolve1.conf to /etc/dbus/system.d/), the -resolved from HEAD starts without issue, however it still doesn't write any domain or search lists. It makes no difference which -networkd I use.

I'm not at home so I can't test the duplicate name servers issue, but I do notice this:

$ grep ^DNS /run/systemd/netif/leases/* /etc/systemd/resolved.conf 
/run/systemd/netif/leases/4:DNS=10.52.0.10 10.0.0.23 10.0.0.17
/etc/systemd/resolved.conf:DNS=2a01:4f8:161:4109::6 2001:4ba0:cafe:383::1
$ cat /etc/resolv.conf 
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

nameserver 10.0.0.23
nameserver 2001:4ba0:cafe:383::1
nameserver 10.0.0.17
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2a01:4f8:161:4109::6
nameserver 10.52.0.10

That is, the current HEAD version reorders the nameserver list. It mixes dhcp-provided resolvers with static ones, and it puts the local dns server last, even though it was listed first in the dhcp answer.

*** Bug 85555 has been marked as a duplicate of this bug. ***

Its still happening on 218. Will it have a fix soon?

I can confirm that this bug still exists in Arch Linux ARM, running systemd 218-2.

Does not confirm issue on ArchLinux x86_64, systemd 219-6. Did you add "UseDomains = yes" to "[DHCP]" section in /etc/systemd/network/your.network? Without it resolved did not add domain suffixes.

Can also confirm that this is fixed by setting "UseDomains" to true.

I wonder why this is not enabled by default.

It defaults to off, because of security considerations.

When 'domain' or 'search' are set, the resolver will attempt to resolve any name using it. In principle this a rogue dns server to spoof domain names.

But rereading things again, I think the concern is overstated, and we can safety set UseDomains=yes by default. I'll continue the thread on the mailing list.

OK, we discussed it a bit on the mailing list [https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html]:

> Altering the search paths is inherently something that makes no sense 
> on public networks, it only makes sense if you know your network well, 
> and trust it to some level. Hence opt-in sounds like the better option

Documentation is extended a bit to make this more visible:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e88d8021ba.