BIND insists on addresses bound to interfaces (at least, that's my
contention, based on experience yesterday, which may or may not reflect
some reality which has been manufactured today).
resolved uses a loopback address which is not bound to an interface (at
least that's my experience, which may or may not reflect some reality
which has been manufactured today).
Nick, I'll ask before the fold: how do I explicitly bind 127.0.0.53 to the
lo interface before systemd starts?
On Sun, 11 May 2025, Nick Tait via bind-users 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?
You know what? I'd like some features too. But I don't go around binding
to addresses which are not bound to interfaces. Never. I just don't do
that. Venturing close to the "political" line: I don't see anything in
BIND which even hints at a whiff of dbus.
* 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.
From where I sit it looks like it sits on an unbound address to shim into
established, conformant, admittedly baroque and crenellated mechanisms for
managing name resolution... I actually laughed when you mentioned NSS
(thanks)... while staying as catastrophically inscrutable as wiring the
red wire to ground; and that this works to its advantage, making it
difficult to remove by people who would never, ever imagine that core
software would abrogate established contractual mechanisms without copious
documentation... and that the best we would do would be apologaeia from
the likes of Fred Morris or Nick Tait!
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.
libc. Granted, your mileage may vary with your implementation, tire
inflation, RAM color and CPU orientation... but charm never matters.
Rhetorically, how much does it take to get your stack explicitly unloved?
I don't know exactly, we don't have a lot of data points.
https://security.opensuse.org/2025/05/07/deepin-desktop-removal.html
As far as I know, BIND has never chosen "DNS eins" as a molehill to die
on.
--
Fred Morris, internet plumber
--
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
