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