Re: My Introduction and current issues -

Have patience.

When the various current DNS resolution mechanisms (systemd-resolved, stub resolvers, resolv.conf, MDNS, on-LAN DNS servers which forward and cache, "secure" lookup over TLS by the browser itself, etc.) are augmented by AI, it will all work perfectly.

Or not.

-----------------------

On Sun, 11 May 2025 12:37:23 +1200
Nick Tait via bind-users <[email protected]> wrote:

> 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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users