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 <[email protected]> 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 -n > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > systemd-n 51 systemd-network 18u IPv6 56615 0t0 UDP > [fe80::685a:94ff:fecc:37ce]:546 > systemd-n 51 systemd-network 20u IPv4 59162 0t0 UDP > 10.200.0.50:68 > rsyslogd 56 syslog 8u IPv4 66478 0t0 UDP *:57004 > salt-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:53 > systemd-r 2519 systemd-resolve 13u IPv4 1272288 0t0 TCP > 127.0.0.53:53 (LISTEN) > > > root@dev ~# ps -ef > UID PID PPID C STIME TTY TIME CMD > root 1 0 0 Sep04 ? 00:00:00 /lib/systemd/systemd > root 18 1 0 Sep04 ? 00:00:00 > /lib/systemd/systemd-journald > systemd+ 51 1 0 Sep04 ? 00:00:00 > /lib/systemd/systemd-networkd > root 52 1 0 Sep04 ? 00:00:00 /usr/bin/python3 > /usr/bin/networkd-dispatcher > root 53 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd-logind > root 54 1 0 Sep04 ? 00:00:00 /usr/sbin/cron -f > message+ 55 1 0 Sep04 ? 00:00:00 /usr/bin/dbus-daemon > --system --address=systemd: --nofork --nopidfile --systemd-activation > --syslog-only > syslog 56 1 0 Sep04 ? 00:00:00 /usr/sbin/rsyslogd -n > root 62 1 0 Sep04 ? 00:00:00 /usr/bin/python > /usr/bin/salt-minion > root 63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u > --noclear --keep-baud console 115200,38400,9600 vt220 > root 68 62 0 Sep04 ? 00:00:34 /usr/bin/python > /usr/bin/salt-minion > root 71 68 0 Sep04 ? 00:00:00 /usr/bin/python > /usr/bin/salt-minion > root 873 1 0 Sep04 pts/0 00:00:00 /usr/bin/fish > root 875 1 0 Sep04 ? 00:00:00 /lib/systemd/systemd --user > root 876 875 0 Sep04 ? 00:00:00 (sd-pam) > systemd+ 2519 1 0 07:42 ? 00:00:00 > /lib/systemd/systemd-resolved > root 3352 873 0 08:06 pts/0 00:00:00 ps -ef > > >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
