Why does /etc/resolv.conf point at 127.0.0.53 in Linux? скачать в хорошем качестве

Why does /etc/resolv.conf point at 127.0.0.53 in Linux?

Why does /etc/resolv.conf point at 127.0.0.53 in Linux? This problem is likely caused by systemd-resolved which is running as a service on your system. Here is the reason why systemd-resolved dynamically generates two configuration files for potential use by DNS client libraries, like the BIND DNS client library in C libraries: /run/systemd/resolve/stub-resolv.conf: This file instructs DNS client libraries to send their queries to 127.0.0.53, which is where the systemd-resolved process listens for DNS queries before forwarding them. /run/systemd/resolve/resolv.conf: This file tells DNS client libraries to send their queries to IP addresses obtained by systemd-resolved on-the-fly from its configuration files and DHCP lease information. This bypasses systemd-resolved's forwarding step but also skips its logic for making complex forwarding decisions based on each transaction. In both cases, systemd-resolved configures a search list of domain name suffixes derived on-the-fly from its configuration files and DHCP leases. The /etc/resolv.conf file can be configured as: A symbolic link to either of the above-mentioned files. A symbolic link to a package-supplied static file at /usr/lib/systemd/resolv.conf, specifying 127.0.0.53 without on-the-fly search domains. Some other custom file. Chances are, you have a symbolic link to one of these files. In this scenario, systemd-resolved manages the 192.168.1.1 DNS setting provided in DHCP leases on your LAN, and your DNS client libraries communicate with systemd-resolved. Interestingly, you might not see loopback interface traffic to/from 127.0.0.53 properly captured because systemd-resolved can optionally bypass the BIND DNS Client in C libraries, thus generating no such traffic to capture. To handle DNS resolution, systemd-resolved uses an NSS module called nss-resolve, which is a plug-in for C libraries. This module replaces the traditional nss-dns plug-in, which uses the BIND DNS Client to perform DNS queries using the DNS protocol with servers listed in /etc/resolv.conf. nss-resolve communicates with systemd-resolved via a non-standard protocol over the Desktop Bus, ahead of nss-dns in /etc/nsswitch.conf. To intercept this communication, you need to monitor the Desktop Bus traffic using tools like dbus-monitor, as it is not regular IP traffic and is reached via an AF_LOCAL socket. If you wish to use a third-party DNS server like 1.1.1.1 instead of 192.168.1.1, you have three options: Configure your DHCP server to distribute the desired DNS server IP (e.g., 1.1.1.1), and systemd-resolved will learn this from DHCP leases. Configure systemd-resolved directly to use the desired DNS server instead of what it finds in DHCP leases. Create your own /etc/resolv.conf file as a regular file (not a symbolic link), specify 1.1.1.1, and disable nss-resolve to revert to using nss-dns and the BIND DNS Client. Configuring systemd-resolved for the second option involves various files and directories and is detailed in the resolved.conf(5) manual page. Here are the commands featured on my video. systemctl stop systemd-resolved systemctl status systemd-resolved nano /etc/resolv.conf_Rabi rm /etc/resolv.conf ln -s /etc/resolv.conf_Rabi /etc/resolv.conf systemctl stop systemd-resolved systemctl status systemd-resolved Worthy mentions cat /run/systemd/resolve/stub-resolv.conf cd /etc #linux #ubuntu #docker #vmware