Re: [systemd-devel] Where does resolved takes its data from?
FWIW the systemd 239+ version of systemd-resolve --status is resolvectl status. On Wed, Sep 5, 2018, 9:40 AM wrote: > systemd-resolved has a DBUS API, which is used by network configuration > managers such as systemd-networkd and NetworkManager to set the hostname > resolution -related configuration to be used by systemd-resolved. > > You can see the runtime configuration of systemd-resolved by running > `systemd-resolve --status`. To see what protocols (DNS, LLMNR, MDNS) are > used to resolve a specific hostname, use `systemd-resolve > somemachine.local`, for example. > > The protocols that are used during hostname resolution can be toggled > per-interface using the same command, or they can be set via the DBUS > API by some network configuration manager. > > Caution: The following is "as far as I know": > Please note that the systemd-resolved DBUS API provides methods to do > hostname resolution with more control over the resolution method than > the functions provided by GNU C libraries. These latter functions > inspect `hosts:` entry of `/etc/nsswitch.conf` to determine plugins that > are used to do hostname resolution, one of which should be `resolve` to > direct queries to systemd-resolved in case the GNU C hostname resolution > API is used. > > Sorry if this veered into the territory of "I didn't ask this question". > I just thought that clarifying the whole picture could help in better > setting up hostname resolution. > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where does resolved takes its data from?
systemd-resolved has a DBUS API, which is used by network configuration managers such as systemd-networkd and NetworkManager to set the hostname resolution -related configuration to be used by systemd-resolved. You can see the runtime configuration of systemd-resolved by running `systemd-resolve --status`. To see what protocols (DNS, LLMNR, MDNS) are used to resolve a specific hostname, use `systemd-resolve somemachine.local`, for example. The protocols that are used during hostname resolution can be toggled per-interface using the same command, or they can be set via the DBUS API by some network configuration manager. Caution: The following is "as far as I know": Please note that the systemd-resolved DBUS API provides methods to do hostname resolution with more control over the resolution method than the functions provided by GNU C libraries. These latter functions inspect `hosts:` entry of `/etc/nsswitch.conf` to determine plugins that are used to do hostname resolution, one of which should be `resolve` to direct queries to systemd-resolved in case the GNU C hostname resolution API is used. Sorry if this veered into the territory of "I didn't ask this question". I just thought that clarifying the whole picture could help in better setting up hostname resolution. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where does resolved takes its data from?
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 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 > COMMANDPIDUSER 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 > rsyslogd56 syslog8u IPv4 66478 0t0 UDP *:57004 > salt-mini 68root 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 > UIDPID PPID C STIME TTY TIME CMD > root 1 0 0 Sep04 ?00:00:00 /lib/systemd/systemd > root18 1 0 Sep04 ?00:00:00 > /lib/systemd/systemd-journald > systemd+51 1 0 Sep04 ?00:00:00 > /lib/systemd/systemd-networkd > root52 1 0 Sep04 ?00:00:00 /usr/bin/python3 > /usr/bin/networkd-dispatcher > root53 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-logind > root54 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 > root62 1 0 Sep04 ?00:00:00 /usr/bin/python > /usr/bin/salt-minion > root63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u > --noclear --keep-baud console 115200,38400,9600 vt220 > root6862 0 Sep04 ?00:00:34 /usr/bin/python > /usr/bin/salt-minion > root7168 0 Sep04 ?00:00:00 /usr/bin/python > /usr/bin/salt-minion > root 873 1 0 Sep04 pts/000: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/000:00:00 ps -ef > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Where does resolved takes its data from?
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 COMMANDPIDUSER 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 rsyslogd56 syslog8u IPv4 66478 0t0 UDP *:57004 salt-mini 68root 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 UIDPID PPID C STIME TTY TIME CMD root 1 0 0 Sep04 ?00:00:00 /lib/systemd/systemd root18 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-journald systemd+51 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-networkd root52 1 0 Sep04 ?00:00:00 /usr/bin/python3 /usr/bin/networkd-dispatcher root53 1 0 Sep04 ?00:00:00 /lib/systemd/systemd-logind root54 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 root62 1 0 Sep04 ?00:00:00 /usr/bin/python /usr/bin/salt-minion root63 1 0 Sep04 console 00:00:00 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 vt220 root6862 0 Sep04 ?00:00:34 /usr/bin/python /usr/bin/salt-minion root7168 0 Sep04 ?00:00:00 /usr/bin/python /usr/bin/salt-minion root 873 1 0 Sep04 pts/000: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/000:00:00 ps -ef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
