Difference between revisions of "Resolv.conf"
Jayctheriot (talk | contribs) (Created page with "Copy/pasted from https://unix.stackexchange.com/questions/694764/how-to-configure-resolv-conf <code>resolvconf</code> was/is a tool designed to allow updates to <code>/etc/resolv.conf</code> file from multiple sources (e.g. DHCP, static configuration by sysadmin, VPN clients, installation of a local DNS server...) in a way that allows the settings from each source to be reverted without interference to the other sources. It also allows setting priorities for each DNS co...") |
(No difference)
|
Latest revision as of 04:33, 8 May 2025
Copy/pasted from https://unix.stackexchange.com/questions/694764/how-to-configure-resolv-conf
resolvconf was/is a tool designed to allow updates to /etc/resolv.conf file from multiple sources (e.g. DHCP, static configuration by sysadmin, VPN clients, installation of a local DNS server...) in a way that allows the settings from each source to be reverted without interference to the other sources. It also allows setting priorities for each DNS configuration source, so that whenever there are more than three DNS server candidates, only the top three candidates will get chosen.
(Unless DNS timeouts are adjusted from defaults, only three query attempts can be made before the query times out, so configuring more than three DNS servers in /etc/resolv.conf is not typically useful.)
However, I think Ubuntu & Mint have migrated to using systemd-resolved instead of the classic glibc DNS resolver. This is true if the hosts: line in /etc/nsswitch.conf has resolve instead of or before dns. This configuration will route any DNS queries performed using glibc's hostname resolution API directly to systemd-resolved without checking /etc/resolv.conf at all. (Technically, libnss_resolve.so is used instead of libnss_dns.so.)
But your system may have some legacy applications that won't use glibc, or DNS diagnostic programs (nslookup, dig etc.) which will implement their own DNS queries, but will read /etc/resolv.conf to find out the default DNS server(s) to use. Because of this, systemd-resolved will by default offer a DNS-server-like interface at 127.0.0.53:53 and (unless this compatibility interface is disabled) will configure /etc/resolv.conf with a nameserver 127.0.0.53 line, so that even the special cases will end up using systemd-resolved.
resolvectl is primarily a tool for managing systemd-resolved, whose functionality is a superset of (the classic libnss_dns.so resolver library + resolvconf). The resolvectl command has some compatibility with resolvconf, however the compatibility is not perfect: instead of modifying existing files in /etc/resolvconf/resolv.conf.d/ or adding a new file to [/var]/run/resolvconf/interface/ and then running resolvconf -u, you can supply per-interface DNS server configuration by resolvectl dns <interface name> 1.1.1.1 8.8.8.8, resolvectl domain <interface name> domain.name.example etc.
Since you seem to have both resolvconf and systemd-resolved installed, you may have the same situation as in Debian 11: man resolvconf will actually display the man page of resolvectl, including its compatibility notes. To view the man page of actual resolvconf, you'll need to type man 8 resolvconf.
The "unstable" in the output of sudo apt changelog resolvconf doesn't mean that version is unstable now: it means at the time that change was made that version was in Debian unstable. For security bugfixes, you would see <releasename>-security in place of unstable. The changelogs are part of the history of the individual package: they won't be rewritten as the package moves from Debian unstable to testing and onward to stable, or from unstable/testing to Ubuntu, Mint or other distributions which draw from Debian.