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 <bind-users@lists.isc.org> 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
