Bug#1125411: resolvconf and forwarding resolver behavior

"Andrej Shadura" <[email protected]> Thu, 12 Feb 2026 15:18:43 +0100
Newsgroups gmane.linux.debian.devel.ctte
Message-ID <ed85b42a-7f8d-4615-9035-d21a008c4730__15490.7870966539$1770908278$gmane$org@app.fastmail.com>
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 resolv=
er
> 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=E2=80=99m 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 p=
urposes 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 wh=
en resolvconf is installed: resolvconf is meant to improve interaction b=
etween different packages wanting to write to /etc/resolv.conf, but its =
mere presence should not be taken as a signal for other software to beha=
ve differently.

In this particular case, my personal expectation would be that installin=
g 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. u=
nbound vs unbound-recursive (Depends: unbound).

For this reason, I objected (and still object) to systemd-resolved decla=
ring Conflicts: resolvconf. I think there are perfectly valid reasons to=
 use resolved with resolvconf.
If I had energy and time, I=E2=80=99d 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 forwardi=
ng
> 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 t=
hink the maintainer of unbound should not switch it to a different mode =
when resolvconf is in use.

--=20
Cheers,
  Andrej