OK , I think I found the reason.
I get the IP via DHCP, which also brings in the DNS servers (the two secondaries). This somehow gets used by resolved, as it puts the resolvers in /run/systemd/resolve/resolv.conf.
Since /etc/hosts is linked to /run/systemd/resolve/stub-resolv.conf which just points to 127.0.0.53, I believe that resolved internallmy sees teh secondaries (provided by DHCP), shows this by putting them into /run/systemd/resolve/resolv.conf and 127.0.0.53 uses that information (also visible via resolvctl status).
This makes sense, leaving /etc/systemd/resolved.conf for static configurations (no DHCP), and probably as a way to overwrite DHCP provided data.
Sorry for the noise.
Le mer. 5 sept. 2018 à 08:11, Wojtek Swiatek <w@xxxxxxxxx> a écrit :
Hello everyone,I decided to clean up my DNS resolving mess and fully go the systemd-resolved way = on every machine:- have /etc/resolv.conf linked to /run/systemd/resolve/stub-resolv.conf- have the resolver stub running on 127.0.0.53- provide internal upstream and fallback servers in /etc/systemd/resolved.conf- hope for the best"every machine" above are actually nspawn containers with their own IP addresses (provided and resolved by the host, via dnsmasq)I removed any other resolvers (if they were present), everything is under networkd control.My first step was to have a broken machine (DNS wise), with a fully commented out /etc/systemd/resolved.conf (as it is by default), expecting not to be able to resolve anything and go from there.To my surprise google.com resolved fine. OK, this must be an invisible default pointing to 8.8.8.8 or something like that (as the fallbacks are still commented out).But I also tried to resolve an internal name, known only by the host and secondary internal servers (which would be the upstream servers mentioned above, when actually configured in /etc/systemd/resolved.conf).I have no idea how resolved managed to get information from other DNS servers (whihc could be either the host, which runs dnsmasq on 0.0.0.0:53, or the secondaries which run bind on their_IP:53)).Where could that resolution come from?The situation on the machines, showing that resolved is the only one resolver:root@dev ~# lsof -i -P -nCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAMEsystemd-n 51 systemd-network 18u IPv6 56615 0t0 UDP [fe80::685a:94ff:fecc:37ce]:546systemd-n 51 systemd-network 20u IPv4 59162 0t0 UDP 10.200.0.50:68rsyslogd 56 syslog 8u IPv4 66478 0t0 UDP *:57004salt-mini 68 root 21u IPv4 829402 0t0 TCP 10.200.0.50:46988->52.210.137.123:4505 (ESTABLISHED)systemd-r 2519 systemd-resolve 12u IPv4 1272287 0t0 UDP 127.0.0.53:53systemd-r 2519 systemd-resolve 13u IPv4 1272288 0t0 TCP 127.0.0.53:53 (LISTEN)root@dev ~# ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 Sep04 ? 00:00:00 /lib/systemd/systemdroot 18 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd-journaldsystemd+ 51 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd-networkdroot 52 1 0 Sep04 ? 00:00:00 /usr/bin/python3 /usr/bin/networkd-dispatcherroot 53 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd-logindroot 54 1 0 Sep04 ? 00:00:00 /usr/sbin/cron -fmessage+ 55 1 0 Sep04 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-onlysyslog 56 1 0 Sep04 ? 00:00:00 /usr/sbin/rsyslogd -nroot 62 1 0 Sep04 ? 00:00:00 /usr/bin/python /usr/bin/salt-minionroot 63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220root 68 62 0 Sep04 ? 00:00:34 /usr/bin/python /usr/bin/salt-minionroot 71 68 0 Sep04 ? 00:00:00 /usr/bin/python /usr/bin/salt-minionroot 873 1 0 Sep04 pts/0 00:00:00 /usr/bin/fishroot 875 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd --userroot 876 875 0 Sep04 ? 00:00:00 (sd-pam)systemd+ 2519 1 0 07:42 ? 00:00:00 /lib/systemd/systemd-resolvedroot 3352 873 0 08:06 pts/0 00:00:00 ps -ef
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
