> 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
> 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
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
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
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
/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
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
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:
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
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
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
20 matches
Mail list logo
