[Expired for systemd (Ubuntu) because there has been no activity for 60
days.]
** Changed in: systemd (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/171480
@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 i
I seem to have a similar (the same) problem. Ubuntu 17.10 - sleep and
resume leaves the resolv.conf with a "search" directive that breaks name
resolution for any name within the domains mentioned in the search
directive.
Trying to resolve any name fails, as e.g.:
% systemd-resolve
: resolve call
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
On 12 October 2017 at 14:55, Matthias Fratz <1714...@bugs.launchpad.net> wrote:
> 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
>
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-
konstanz.de
On 11 October 2017 at 15:25, Matthias Fratz <1714...@bugs.launchpad.net> wrote:
> 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
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:
[ipv4]
On 10 October 2017 at 15:39, Matthias Fratz <1714...@bugs.launchpad.net> wrote:
> 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.i
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.)
Wha
Hm.
So my local WiFi router is setup to send 'surgut.co.uk' domain. And I
can resolve 'blog.surgut.co.uk' and 'surgut.co.uk' via both `systemd-
resolve [blog.]surgut.so.uk` and `getent ahosts [blog.]surgut.co.uk`.
I think i really need to see all of the settings for systemd can you
attach a tarba
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
probably
In 17.10 this has changed to a behaviour consistent with e.g. 16.04.
Search domains are properly trusted and are configured in resolved via its dbus
api.
The generated /etc/resolv.conf contains resolved stub resolver and search
domains out of the box (those e.g. acquired via dhcp, or configured i
13 matches
Mail list logo
