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 ONLY gives the ipv4 address (as I had already checked before opening this ticket, and which also made me very positive that the local resolver was to blame).
Unfortunately, the log doesn't really show much about where it gets what data from... Dez 06 09:02:14 fpc systemd-resolved[25637]: Got DNS stub UDP query packet for id 24958 Dez 06 09:02:14 fpc systemd-resolved[25637]: Looking up RR for fpc IN A. Dez 06 09:02:14 fpc systemd-resolved[25637]: Sending response packet with id 24958 on interface 1/AF_INET. Dez 06 09:02:14 fpc systemd-resolved[25637]: Processing query... Dez 06 09:02:14 fpc systemd-resolved[25637]: Got DNS stub UDP query packet for id 63588 Dez 06 09:02:14 fpc systemd-resolved[25637]: Looking up RR for fpc IN AAAA. Dez 06 09:02:14 fpc systemd-resolved[25637]: Sending response packet with id 63588 on interface 1/AF_INET. Dez 06 09:02:14 fpc systemd-resolved[25637]: Processing query... Dez 06 09:02:14 fpc systemd-resolved[25637]: Got DNS stub UDP query packet for id 13823 Dez 06 09:02:14 fpc systemd-resolved[25637]: Looking up RR for fpc IN MX. Dez 06 09:02:14 fpc systemd-resolved[25637]: Cache miss for fpc IN MX Dez 06 09:02:14 fpc systemd-resolved[25637]: Transaction 22387 for <fpc IN MX> scope dns on */*. Dez 06 09:02:14 fpc systemd-resolved[25637]: Using feature level UDP for transaction 22387. Dez 06 09:02:14 fpc systemd-resolved[25637]: Using DNS server 10.2.2.3 for transaction 22387. Dez 06 09:02:14 fpc systemd-resolved[25637]: Sending query packet with id 22387. Dez 06 09:02:14 fpc systemd-resolved[25637]: Processing query... Dez 06 09:02:14 fpc systemd-resolved[25637]: Processing incoming packet on transaction 22387. (rcode=SUCCESS) Dez 06 09:02:14 fpc systemd-resolved[25637]: Not caching negative entry without a SOA record: fpc IN MX Dez 06 09:02:14 fpc systemd-resolved[25637]: Transaction 22387 for <fpc IN MX> on scope dns on */* now complete with <success> from network (unsigned). Dez 06 09:02:14 fpc systemd-resolved[25637]: Sending response packet with id 13823 on interface 1/AF_INET. Dez 06 09:02:14 fpc systemd-resolved[25637]: Freeing transaction 22387. At that minute&second I did a "host fpc". The log entries before and after had sufficiently separate timings. (I repeated it a few times, until other requests from other applications didn't mix in.) This is what I get from asking "upstream" DNS directly: $ nslookup fpc 10.2.2.3 Server: 10.2.2.3 Address: 10.2.2.3#53 Name: fpc Address: 10.2.2.1 $ That machine 10.2.2.3 is still running Ubuntu 16.04 and dnsmasq. -- 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 in Ubuntu: Incomplete Bug description: 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 two addresses: the correct ipv4 address, and a broken ipv6 address. Unlike on ipv4, it is possible for the same ipv6-address to be assigned to multiple devices, and therefore the address is only valid in the context of the eth-device. Now, if "ifconfig" shows "inet6 fe80::4687:fcff:fe9e:4ac7 prefixlen 64 scopeid 0x20<link>" then "fe80::4687:fcff:fe9e:4ac7" is NOT a connectable address, and syscall connect() typically fails with EINVAL. To make it a valid address, it needs to be suffixed with a "%" and the device name, like: fe80::4687:fcff:fe9e:4ac7%enp4s0 Either the resolver can return the link name attached to the address separated with a "%" char, or it needs to ignore link-local inet6 addresses. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853669/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
