Why does /etc/resolv.conf point at 127.0.0.53 in Linux?
Автор: Slap Ya Administrator
Загружено: 2023-10-27
Просмотров: 6435
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
Доступные форматы для скачивания:
Скачать видео mp4
-
Информация по загрузке:
