Public bug reported:
I've got an ethernet-device that only has a configured ipv4 address, and
some auto-generated link-local (aka "scope link") ipv6 address.
Any tool doing a DNS query (and /lib/systemd/systemd-resolved is the
DNS-server listening on 127.0.0.53) for this host's hostname gets back
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 is
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 the
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 how
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 tha
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: fe80::4687:fc
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 systemd-
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
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 ON
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 sys
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, wh
/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 Serv
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 re
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
t
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
> 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 fe80::4687:fcff:fe9e:4ac7..
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 Ubun
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 b
> 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 wh
> 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 upst
20 matches
Mail list logo
