From: andrewsh@debian.org   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)