[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
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: systemd (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853669
Title:
systemd resolves own hostname to link
** Tags added: ddstreet
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853669
Title:
systemd resolves own hostname to link local ipv6 address
Status in systemd package
> It really looks like as if systemd-resolved looked for the configured
nameservers, recognized itself and took the other one as upstream.
it may, it depends entirely on your network configuration, which I don't
know.
> Will look for where to create ticket for upstream systemd tomorrow. or
when
> you haven't told resolved about any upstream nameservers ...
As I said, my original resolv.conf just had two nameserver entries, the
local one (127.0.0.53) and the upstream one.
>From that, all the diagnose-calls we did during this thread seemed to
show that systemd-resolved DID know the
> In my resolv.conf I have now both 127.0.0.53 and the upstream dns each
in their own "nameserver"-line.
if you haven't told resolved about any upstream nameservers, there is no
point in pointing resolv.conf to it.
> "telnet" is just a simple tool to connect to tcp/ip endpoints, in case
you
> but it will bypass resolved completely
In my resolv.conf I have now both 127.0.0.53 and the upstream dns each
in their own "nameserver"-line. Just as in comment #17, but in the
meantime I added domain and search lines.
> you want to telnet to your local host?
I really wanted to demonstrate
> Ok, so adding it to /etc/resolv.conf is actually one of the supported
ways.
well, I wouldn't call it 'supported' as you're then responsible for
managing the resolv.conf file, but it will bypass resolved completely
(assuming you don't put 127.0.0.53 in the file, and you only use your
upstream
Is the factual incorrectness of "All the ipv6 addresses it resolves for
its own hostname are reachable locally" understood? They are *only*
reachable, if the interface is provided along with the link local
inet6-address, but that extra condition isn't met.
--
You received this bug notification
PS: I also appreciate all the other mechanisms for having upstream dns
set up from dhcp or other dynamic connections. Just that one machine is
set up statically.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in
> If you manually configure your network, ...
Ok, so adding it to /etc/resolv.conf is actually one of the supported ways.
Thanks (for info). I'll stick to that.
> Why is it wrong?
try connecting to that address:
avl@fpc:~$ telnet fe80::4687:fcff:fe9e:4ac7 22
Trying
> Result is, that localhost's systemd-resolved now no longer
> knows about upstream dns 10.2.2.3 -- where else am I supposed
> to configure that?
If you use systemd-networkd to configure your network (or, netplan,
which will indirectly configure networkd or network-manager for you),
then
I do agree that it is correct(TM) behaviour to not ask upstream DNS for
bare ("single label") names. But this is not what this bugreport was
about.
The point is what systemd-resolved does in such a case, where it cannot
consult upstream DNS, and also doesn't find the name in local
/etc/hosts:
It
Ok, just to check, I changed /etc/resolv.conf to remove second
nameserver, added "domain .hm" and "search hm", added "fpc.hm"
to the respective entry in 10.2.2.3's /etc/hosts.
Result is, that localhost's systemd-resolved now no longer
knows about upstream dns 10.2.2.3 -- where else am I supposed
> /etc/resolv.conf:
> nameserver 127.0.0.53
> nameserver 10.2.2.3
You shouldn't hand-edit your resolv.conf file; don't put the upstream
nameserver in there.
Anyway, assuming you haven't edited out the search domain because you
thought it wasn't relevant, you're using single-label hostnames,
Apologies...
I'll leave out the comment-headers and just paste the relevant contents:
/etc/resolv.conf:
nameserver 127.0.0.53
nameserver 10.2.2.3
/etc/systemd/resolved.conf:
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
--
You
You missed contents of /etc/resolv.conf
Also paste contents of /etc/systemd/resolved.conf
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853669
Title:
systemd resolves
/etc/hosts:
127.0.0.1 localhost
127.0.1.1 kato i7
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
$ systemd-resolve --status
Global
DNS
> I don't understand what lsof tries to tell me here, but naively I'd
assume that systemd-resolved also queries the routing table, and for
that I also attach the output of "route -n -6" at the end of this
message.
that's not correct.
What's the contents of your /etc/hosts file? Contents of
Here is some more info, namely an "strace" of the systemd-resolved
program.
(An "lsof"-excerpt with the open channels follows the trace-log, to make
sense of filedescriptors)
In a nutshell: at some point, it receives the inet6 address
"fe80::4687:fcff:fe9e:4ac7" in an "recvmsg" call on FD 9,
It occurred to me, that the actual query might be cached at that time,
so I did a fresh restart of systemd-resolved and query, and then
follows the log for these times: I don't see much relevant details in
it, except that it also tries to find MX-records but fails till
.
avl@fpc:~$ date; sudo
Well, ok, here is the real data: my hostname is "fpc" and really has
IPv4 10.2.2.1, the next upstream nameserver is another machine in my
home network, 10.2.2.3 which is configured to also use its /etc/hosts
(so I only need to maintain it on one machine). Doing the nslookup
directly on 10.2.2.3
> It was no "assumption", but an "observation".
no, you are assuming that systemd-resolved is the authoritative
nameserver providing the $(hostname) addresses, which is wrong.
systemd-resolved is a stub nameserver that does no authoritative
resolution itself; it gets its answers from other
PS: re "assumption"/"observation" -- ok, that it would happen for you
was indeed just an assumption.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1853669
Title:
systemd
If your (same-version?) systemd does not return the link local address
to nslookup, then I'd appreciate a hint for what kind of config would
make it do so, so I could check the particular files.
I just recently upgraded my machine from 16.04 (with dnsmasq) to 18.04
-- if I had changed any
It was no "assumption", but an "observation".
$ nslookup $(hostname) # a blank name without any domain
Server: 127.0.0.53
Address:127.0.0.53#53
Non-authoritative answer:
Name: xxx # my "$(hostname)"
Address: 192.168.0.1
Name: xxx
Address:
> In my case, "ifconfig enp4s0" shows a line like this:
> inet6 fe80::4687:fcff:fe9e:4ac7 prefixlen 64 scopeid 0x20
this is normal, when ipv6 is enabled; all interfaces get a link-local
address.
> run "host $(hostname)" and it is likely to return...the link local
inet6 address.
Your
If you see the bare inet6 link local address, but just can't see a problem with
it,
then try:
$ telnet $(hostname)# some port that isn't listened on.
Trying 192.168.0.1...
Trying fe80::4687:fcff:fe9e:4ac7...
telnet: Unable to connect to remote host: Invalid argument
The symptom being here
The premis is that you have a network device with a "link local" (aka:
"scopeid 0x20") inet6 address.
In my case, "ifconfig enp4s0" shows a line like this:
inet6 fe80::4687:fcff:fe9e:4ac7 prefixlen 64 scopeid 0x20
If your machine does NOT have such a line, then I must admit, I don't
know
I can't reproduce this, can you provide specific cmdline steps to
reproduce please.
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Most of the times, the first hit (namely the ipv4 address) is all that
is used from the DNS query.
In my case, it is essentially a testcase for Tcl's socket, which tries
to establish a connection to an unlistened port, and expects a
"connection refused" error. But Tcl in this case(namely that
Afternotes: I only noticed the bug shortly after upgrading from Ubuntu
16.04 to Ubuntu 18.04
Seems like 16.04 didn't yet use systemd-resolved, but dnsmasq, which
only returned ipv4 addresses.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
32 matches
Mail list logo
