On 11/05/2025 07:28, Fred Morris wrote:
Stop! Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive
off systemd resolved. Then make sure that resolv.conf is not being
hijacked.
Now try again.
Contrary to popular opinion -- on this list at least -- systemd-resolved
is /not/ evil. It is just misunderstood...
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:
* Systemd-resolved is the resolver component of the systemd suite.
(From Wikipedia <https://en.wikipedia.org/wiki/Systemd>: "systemd is
a software suite that provides an array of system components for
Linux operating systems.")
* Ubuntu uses systemd, including systemd-resolved by default.
* 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.
* 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.
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:
$*getent hosts ip6-loopback*
::1 ip6-localhost ip6-loopback
$*host ip6-loopback*
Host ip6-loopback not found: 3(NXDOMAIN)
(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.)
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 /don't/ 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...
Getting back to the features of systemd-resolved:
* It is a one-stop shop for host name resolution. It can provide:
o synthetic records (including localhost, and the host's own name
-- which admittedly isn't necessarily a good thing).
o LLMNR (which is kind of obsolete now) for single-label names.
o MDNS for names with ".local" suffix.
o DNS for multi-label names (excluding ".local" suffix), and
single-label names with search suffix applied to them.
* I like the fact that it 'feels' like part of systemd, including
stuff like:
o You can specify search domains in your netplan configuration
(using networkd as the renderer in netplan).
o The "resolvectl" utility feels like a sibling to the other
systemd utilities like "systemctl", "journalctl", etc.
Nick.
P.S. I hope I'm not (re-) starting some sort of holy war. That is not my
intention, and I'm definitely /not/ trying to say that everyone should
use systemd-resolved. I'm just trying to be an "active bystander". :-)
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
