<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 11/05/2025 07:28, Fred Morris wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LSU.2.21.2505101207300.16819@flame.m3047">Stop!
Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive
off systemd resolved. Then make sure that resolv.conf is not being
hijacked.
<br>
<br>
Now try again.
</blockquote>
<p>Contrary to popular opinion -- on this list at least --
systemd-resolved is <i>not</i> evil. It is just misunderstood...<br>
</p>
<p>Yes it is complex, and yes you can avoid that complexity by
getting rid of it. But it also has a few features that I
personally find useful. So before you run off to get rid of it,
let me at least highlight some of those features? But first, let
me set the record straight on a few things:<br>
</p>
<ul>
<li>Systemd-resolved is the resolver component of the systemd
suite. (From <a moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/Systemd">Wikipedia</a>:
"systemd is a software suite that provides an array of system
components for Linux operating systems.")<br>
</li>
<li>Ubuntu uses systemd, including systemd-resolved by default.</li>
<li>In the default set-up, systemd-resolved provides a local DNS
stub listener on the IP addresses 127.0.0.53 and 127.0.0.54 on
the local loopback interface, and /etc/resolv.conf is a symbolic
link to /run/systemd/resolve/stub-resolv.conf. This is done to
allow name resolution on the local machine to be serviced by the
local systemd-resolved service.<br>
</li>
<li>The systemd-resolved service has its own configuration which
determines which mechanisms to use to answer name resolution
queries, and (assuming that it is configured to use DNS) which
DNS server(s) to use as a recursive resolver.<br>
</li>
</ul>
<p>I could be mistaken, but my belief is that the goal of this
set-up was to make name resolution work consistently, regardless
of which mechanism (i.e. C function call) is used by an
application. To illustrate my point, here is the output I get from
two different name resolution utilities when trying to resolve a
name that only exists in my /etc/hosts file:</p>
<blockquote>
<pre>$ <b>getent hosts ip6-loopback</b>
::1 ip6-localhost ip6-loopback
$ <b>host ip6-loopback</b>
Host ip6-loopback not found: 3(NXDOMAIN)</pre>
</blockquote>
<p>(The reason for this difference is that the "getent" command uses
the NSS library to resolve the name, which checks my /etc/hosts
file before going to DNS; whereas the "host" command uses the
Resolver library which only uses DNS.)<br>
</p>
<p>Unfortunately there are (or at least were) problems with the
default set-up, including the limitation that the stub listener
wouldn't pass through the AD flag in a DNS response. (The AD flag
is used with DNSSEC to indicate that the data is authentic.) I'm
not sure if this has been fixed, but this is/was a good reason not
to use the stub listener -- and is the reason I <i>don't</i> use
the stub listener. Luckily the stub listener can be easily
disabled by setting "DNSStubListener=no" in the systemd-resolved
configuration. But of course doing this means that
systemd-resolved isn't being used for much (if anything). So at
this point (to continue to use it at all) it is necessary to
install the nss-resolve library and tweak your /etc/nsswitch.conf
file. But I'm not going to get into that detail in this email...<br>
</p>
<p>Getting back to the features of systemd-resolved:<br>
</p>
<ul>
<li>It is a one-stop shop for host name resolution. It can
provide:</li>
<ul>
<li>synthetic records (including localhost, and the host's own
name -- which admittedly isn't necessarily a good thing).</li>
<li>LLMNR (which is kind of obsolete now) for single-label
names.<br>
</li>
<li>MDNS for names with ".local" suffix.</li>
<li>DNS for multi-label names (excluding ".local" suffix), and
single-label names with search suffix applied to them.</li>
</ul>
<li>I like the fact that it 'feels' like part of systemd,
including stuff like:</li>
<ul>
<li>You can specify search domains in your netplan configuration
(using networkd as the renderer in netplan).</li>
<li>The "resolvectl" utility feels like a sibling to the other
systemd utilities like "systemctl", "journalctl", etc.<br>
</li>
</ul>
</ul>
<p>Nick.<br>
</p>
<p>P.S. I hope I'm not (re-) starting some sort of holy war. That is
not my intention, and I'm definitely <i>not</i> trying to say
that everyone should use systemd-resolved. I'm just trying to be
an "active bystander". :-)<br>
</p>
</body>
</html>