My Introduction and current issues -

[Nick Tait]

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". :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250511/cefa79a2/attachment-0001.htm>