@toto-23, you may want to try putting the following in
/etc/systemd/resolved.conf as a temporary workaround:
[Resolve]
Domains=
Note that there is nothing after the equals sign. According to the docs
it will override anything systemd-resolved reads from /etc/resolv.conf
with an empty list. This
In fact it's slightly simpler in that both a.example.com and
b.example.com are public domains. (This is why I put them in the global
config to begin with; these domains will resolve over any nameserver.)
Thus it's not so much that queries for b.example.com don't go to
W.X.Y.Z; it's that they don't
As for ubuntu.com, that was only as an example to show a situations when
things break. I really just copied what the original submitter used -- I
should probably have used example.com instead though, that's less
confusing.
My concrete situation is that the server delivers only inf.uni-
Tried that, and it started using the DHCP-provided search path (yay!).
Setting the search path in NetworkManager (which is responsible for the
interface in question) works, ie. honors the search path and doesn't
break resolving for those domains, with both single and multiple search
paths:
Our DHCP server delivers a search domain (inf.uni-konstanz.de) as well.
This isn't enough to trigger the bug for me, though, at least on 17.04.
(systemd-resolve doesn't actually USE the search path, so merkur236.inf
.uni-konstanz.de works but merkur236 doesn't, but that's a different
problem.)
I can confirm that the underlying bug still exists in today's artful
nightly CD.
I wasn't able to get a search path to stick in /etc/resolv.conf, but
setting Domains=ubuntu.com in /etc/systemd/resolved.conf triggers the
same bug: It breaks resolution for ubuntu.com and www.ubuntu.com (and
