On 1/14/26 00:33, Helmut Grohne wrote: Hi! Thank you for your analysis Helmut!
.> Generally, when packaging software in a large distribution, consistency
between software packages is useful. Therefore looking at how other resolvers behave by default is relevant here. The resolvconf package specifically exists as a glue between network configuration and resolvers to implement forwarding behavior. For instance, dnsmasq also provides such a hook by default. systemd-resolved does not provide such a hook, but when used with systemd-networkd, it also defaults to forwarding behavior. Counter-examples are bind9 and knot, which do not pick up servers to forward to via resolvconf. We can conclude that both ways are prevalent in Debian.
The key point here is that dnsmasq and systemd-resolved are unable to perform recursive resolving entirely, they can not work without a more capable upstream nameserver which is provided via dhcp or by other similar ways, including resolvconf. While both knot and bind9 *are* capable of doing recursive queries. From the 5 examples, unbound falls to the second category - full recursive resolvers. While other two (dnsmasq, systemd-resolved) relies on upstream recursive resolvers. So from this point of view, unbound should not enable the resolvconf hook by default. Thanks, /mjt
