Hello,

First of all, sorry for the delayed response.

On Thu, 5 Feb 2026, at 11:13, Helmut Grohne wrote:
> Hi Andrej at al,
>
> I'm reaching out to you on behalf of the CTTE. We have a dispute on the
> behavior of unbound when resolvconf is installed. The submitter argues
> that resolvconf should not be turning unbound into a forwarding resolver
> as its description indicates it to be recursive.
>
> How do you see this?
>
> The resolvconf package description indicates that caches and resolver
> libraries should be affected. While unbound can cache, it also is a
> recursive resolver. Would you expect unbound to become a forwarding
> resolver upon installing resolvconf?

I’m not the original author of resolvconf, so I cannot say what was the 
original intent when it was created.
However, my understanding is that reconfiguring other software for the purposes 
other than fulfilling the primary aim, which is managing resolv.conf, is beyond 
the scope of resolvconf.

I would not expect other software to drastically change its behaviour when 
resolvconf is installed: resolvconf is meant to improve interaction between 
different packages wanting to write to /etc/resolv.conf, but its mere presence 
should not be taken as a signal for other software to behave differently.

In this particular case, my personal expectation would be that installing 
unbound while having resolvconf should result in unbound behaving the same way 
as if resolvconf was not installed, be it in recursive mode or not. Selecting a 
mode should probably be done either as a configuration setting, or as a binary 
package shipping a configuration snippet, e.g. unbound vs unbound-recursive 
(Depends: unbound).

For this reason, I objected (and still object) to systemd-resolved declaring 
Conflicts: resolvconf. I think there are perfectly valid reasons to use 
resolved with resolvconf.
If I had energy and time, I’d have brought this up with CTTE.

> We also observe that there are two distinct functions both implemented
> by resolvconf. One is to manage /etc/resolv.conf to point it at
> a local recursive resolver (e.g. bind, dnsmasq, unbound, ...) or
> externally provided servers (e.g. /etc/network/interfaces or DHCP). The
> other function is to reconfigure a local resolver to become a forwarding
> resolver for the externally provided servers. Plausibly, both functions
> could be viewed separately, but resolvconf combines them. Is that
> intentional?
>
> The package description of resolvconf does not clearly answer this. We
> suggest updating it. If the forwarding behavior is intended, it would be
> good if the description included that term.

I think reconfiguring any resolvers is out of scope of resolvconf.

To sum it up, as much as I sympathise with the captive portal issue, I think 
the maintainer of unbound should not switch it to a different mode when 
resolvconf is in use.

-- 
Cheers,
  Andrej

Reply via email to