I am escalating bug #1124968 to the Technical Committee after
disagreement with the unbound maintainer.

SUMMARY OF DISPUTE:

The unbound package has a resolvconf hook enabled by default that
silently forwards all DNS queries to upstream resolvers (ISP, hosting
provider) instead of performing recursive resolution.

The maintainer argues:
This is necessary for captive portal scenarios,
and therefore working out of the box in all contexts.

I argue:
- It currently does not work as a resolver out of the box
(as soon as you have a DHCP server on the network, so lots of cases)
- This defeats unbound's documented purpose as a recursive resolver
- It creates a silent privacy leak (all DNS queries sent to third parties)
- It's a security issue (cache poisoning exposure, DNSSEC bypass)
- Users installing a "recursive resolver" expect recursive resolution
- Captive portals are an edge case for unbound's typical userbase

The maintainer marked the bug "wontfix" and suggested escalation.

RELEVANT BUG: #1124968
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124968

PROPOSED RESOLUTION:
- Default to disabled hook (recursive resolution)
- Document how to enable forwarding for captive portal scenarios

OTHER SOLUTION MAY BE:
- Disable (default) / Enable upstream forwarding via config file
- Offer to choose upstream servers (default DHCP)

Thank you
LRob

Hello,

Your disagreement is received. I have marked myself as owner of this bug
which makes me assume the moderator role for this matter on behalf of
the ctte.

As far as I can see, configuring unbound as a recursive resolver is a
matter of changing the execute permission of a conffile. The
functionality you would like to see does exist and the disagreement
only exists about the default behavior of the unbound package. Do you
agree with this characterization?

In order to use the resolvconf hook, the resolvconf package must be
installed. resolvconf is not a dependency of unbound. Therefore removing
the resolvconf package is another way to opt out of the forwarding
behavior. When using unbound as a local resolver, /etc/resolv.conf can
be configured statically and installing the resolvconf package bears
little benefit unless one wishes to communicate the DNS servers received
via DHCP to the local resolver. Do you also concur here?

What made you install the resolvconf package?

Generally, deciding about the defaults of how packages behave - even if
it deviates from upstream choices - is something that falls within the
competence of package maintainers. Deviating from upstream defaults is
not uncommon.

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.

Would you want to further investigate the consistency aspect to provide
a stronger reason in your favour?

Helmut for the technical committee

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

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

Hello Helmut, hi again Michael,

Thank you for taking this matter into consideration.

 > Do you agree with this characterization?

Yes, the disagreement is solely about the default behavior.
The functionality to disable forwarding exists and works.

 > What made you install the resolvconf package?

I did not consciously install it.
In this case it was likely pulled as a dependency or pre-installed
in the server provider's OS install image. I suspect this is the case
for many users who are unaware of its interaction with unbound.

 > Do you also concur here?

Yes, removing resolvconf is another workaround I didn't think of.
However, users who installed unbound for recursive resolution
are unlikely to know that an unrelated package silently changes
unbound's behavior.

 > Would you want to further investigate the consistency aspect?

Michael's latest analysis covers this well and I fully agree with it.

- bind9: no forwarding by default
- knot: no forwarding by default
- dnsmasq: forwards by default (but dnsmasq is primarily a forwarder)
- systemd-resolved: forwards (but it's not marketed as recursive)

Unbound's documentation and purpose align with bind9/knot (recursive
resolution), not with dnsmasq/systemd-resolved (forwarding/caching).

I note that Michael has now reconsidered his initial position: unbound
belongs to the "full recursive resolver" category alongside bind9 and
knot, and therefore should not enable the resolvconf hook by default.

This aligns with my original argument. I'm glad we reached consensus.

What are the next steps to implement this change?

Thank you both,
LRob

Hello LRob,

At this time, I would argue that users who are not aware of resolvconf
likely are also not aware of the distinction between recursive
resolution and forwarding. They just want DNS to work. The way to make
it just work in most situations is forwarding as has been explained in
detail by Michael.

Arguably, the default behavior actually is recursive resolution as you
desire. I verified this by booting a forky VM. Then I installed unbound
and verified that it was not forwarding anywhere. resolvconf was not
installed.

Given resolvconf's package description, I would not be surprised if it
changed unbound's forwarding behavior upon package installation. That
looks exactly like the task the package is solving.

Conversely, if changing the default, I would expect bug reports arguing
that the integration of unbound with resolvconf would be broken by
default. It is perfectly reasonable to use unbound as a forwarding
DNSSEC validator. How do you imagine users to change unbound to
forwarding if they so desire?

Classifying resolvconf as unrelated is a stretch.

Indeed, this changes the argument towards your view. However, I expect
that the user base that both cares and knows the distinction of
forwarding and recursive and at the same time doesn't know about the
purpose of the resolvconf package is relatively small, but I do not
actually have any data on this. A minor data point is that this behavior
has existed for probably a decade without anyone complaining.

I am not yet seeing consensus on this matter.

Helmut

Hello Helmut,

Thanks again for your time and efforts to sort this issue.

 > At this time, I would argue that users who are not aware of resolvconf
 > likely are also not aware of the distinction between recursive
 > resolution and forwarding. They just want DNS to work.

I would argue the opposite: users who just want DNS to work don't
install unbound at all. They use whatever their system provides.

Unbound is not installed by default, as far as I know with Debian.
Users who explicitly install a
"validating, recursive, caching DNS resolver" (package description)
likely do so intentionally and expect recursive resolution.

That was my case, and I didn't expect another package would
ever take over Unbound's configuration. Especially since I had
resolvconf and Unbound installed together on previous installs
without this behavior.

Additionally, knowing about recursive DNS and choosing to install
unbound does not imply knowledge of resolvconf and its hook system.
These are different domains of expertise. A sysadmin can perfectly
understand DNS recursion while being unaware of Debian's resolvconf
framework and hooks will impact other packages like Unbound.

If I understand popcon, resolvconf is nearly 3x more prevalent,
meaning many unbound users may have resolvconf already present
without consciously choosing it. resolvconf is just there, you don't
think about it until it becomes noticeable like in this case.

 > A minor data point is that this behavior has existed for probably
 > a decade without anyone complaining.

Absence of complaints doesn't mean absence of problems.
And I am complaining, so now, that makes at least one.

Also, I believe this behavior was not enabled previously.
Or at least it wasn't since Debian 10/11/12 which about matches
the time I've been using Unbound for recursion.
The script itself states:

# This hook was disabled by default for several releases because of the
# above reasons, by giving out the executable bits of this file, but it
# is now enabled for new installs.

Given my usage, I would have been very likely to notice the issue
earlier if it was not actually recursive before.
This server was my first Trixie install ever, and also the very first time
I noticed the issue.
So I think the change was introduced recently, with Trixie.

Most users likely never realized their "recursive resolver" was
forwarding. Or didn't bother reporting. Until now.

I ran unbound for 2 months before discovering this almost by chance
just because I had inconsistent DNS values after a zone change, on my
monitoring system that depends on Unbound's recursive resolutions.
I monitor website response times after migration.
Time was inconsistent, so I checked server logs and noticed it was
randomly polling the older server... Then I started debugging.

I found the root cause so dangerous and absurd that I had to report it.

Why dangerous? Because...
 From Europe I am just annoyed by having my DNS queries leaked,
and my DNS TTL not respected. Made me lose a few debug and report
hours... A loss of time is annoying but I can get over it.
But in some countries, DNS leakage is a matter of life or death.
Technically, it's just a chmod, but it implies a lot more.
Mass surveillance can also be another problem.
I don't think this is the place to do politics.
But we can probably agree that a chmod which may endanger lives
(even a single one, likely more) is the worst possible thing to happen.
And this alone should in my opinion take over any technical matter.

I think it's not a user's preference or a use case matter.
It's just a huge data leakage and security threat that requires urgent
addressing.

 > How do you imagine users to change unbound to forwarding if they
 > so desire?

chmod +x /etc/resolvconf/update.d/unbound

Same mechanism, opposite default. Users who want forwarding make a
conscious choice. Users who want recursion (unbound's primary purpose)
get it out of the box.

This raises a broader question: is unbound being installed by default
on some systems purely as a forwarder? If so, perhaps the real issue
is misusing unbound for a purpose it was not designed for. dnsmasq or
systemd-resolved would be more appropriate for pure forwarding.
Using a full recursive resolver just to forward queries seems like
the wrong tool for the job.

 > I am not yet seeing consensus on this matter.

In his last answer, Michael seemed to agree the hook should be
disabled by default.
I agree with Michael's latest position.
To me, that's both parties aligned.
Unless I misunderstood something.

What additional input would help reach a decision?

Thank you,
LRob

since I haven't seen anyone pointing to yet:

network-manager (relatable situation) solved this via an extra binary
package network-manager-config-connectivity-debian.

I'd argue for privacy by default, so unbound could recommend or suggest
a new binary package unbound-$whatever containing the hook.

imho that is an acceptable compromise for everyone/every use case.

Regards,
Daniel

I've checked my servers and must add a detail for transparency:
Some of my servers have resolvconf, some don't.
Including some at the same providers.
I myself don't recall ever installing it consciously.
Unfortunately I don't have my previous resolvers available anymore
to check if they had resolvconf or not.
So it is possible that it's my first time having both resolvconf
and Unbound installed on a single machine and therefore
it would still be my first time encountering the case/issue.

Daniel's proposition seems reasonable to me.
A separate package for the forwarding hook would make the choice
explicit and conscious, which addresses the core issue: users
should not have their privacy silently reduced without opting in.
Though it adds complexity for maintainers.

Thanks,
LRob

Hi,

Maybe this is where we should actually look. While the resolvconf
package used to be commonly recommended, systemd-resolved and
NetworkManager provide a sensible alternative for significant use cases.
Maybe it is time to lower recommends on resolvconf to suggests in some
places such that it does not get installed as often?

Please spend some more time figuring out how it came onto your system. I
think this is a key aspect here. You appear to believe that the
forwarding behavior was opt-out, because you do not perceive the
installation of resolvconf as opting in.

Daniel's proposal is enabling the hook via a separate package. How about
naming that package "resolvconf"? Seriously, turning unbound into a
forwarding resolver very much is what I would expect to happen when
installing resolvconf without any extra steps involved. That's what its
package description says.

A cynical voice suggests that we finally reached agreement the other way
round as the resolvconf package very much is an opt-in mechanism. As you
confirmed, it is not installed by default. Can we close this bug now?

Of course this is not what you want, so let us continue the discussion
until we really reach consensus or agree to disagree.

Helmut

Hi all,

Given this command:

    $ apt rdepends --no-suggests --no-conflicts --no-enhances --no-replaces resolvconf | grep -v '^    '
    resolvconf
    Reverse Depends:
      Recommends: resolvconf-admin
      Recommends: whereami
      Depends: netctl
      Recommends: rdnssd
      Recommends: debian-edu-config
      Recommends: education-common
      Recommends: ceni

It may be possible that it was installed transitively via rdnssd, which
is recommended by ifupdown-ng. I find it unlikely that LRob had any of
the others packaged installed on the system.

In any case, a command like `apt why resolvconf` may give a more helpful
answer than trying to figuring it out via rdepends.

Bye!

Hello,

For the record, on my system:
$ aptitude why resolvconf
i   isc-dhcp-client Suggests resolvconf

My provider included it in their image.
But this investigation is beside the point.

The core issue: one package should not silently alter another package's
primary behavior.
Regardless of how resolvconf ended up on a system, a recursive resolver
like unbound should not silently become a forwarder.

1. Installing resolvconf is not "opting in" to change unbound's behavior.
2. Users install resolvconf to manage /etc/resolv.conf, not to turn their
recursive resolver into a simple forwarder.
-> These are two separate intents.

As for the captive portal argument: who runs Unbound locally on a laptop?
And even if they did, modern systems like Fedora/KDE bind custom DNS to
specific networks - connecting to a new hotspot defaults to DHCP DNS.

To sum up:
The current behavior shows little to no benefit while causing major issues.
It breaks intended features... And breaks trust for the unbound package.

I do trust you'll find the best solution as experienced dev/maintainers.
I have no real preference as long as packages go back to being reliable.

Thanks,
LRob

Hi LRob,

A suggested package would not be installed upon installing
isc-dhcp-client.

And this is where we disagree. The stated purpose of the resolvconf
package is to modify system behavior. This is not new. There are several
packages in the archive that perform configuration on other packages.

Again, I disagree. If you opt to installing a package whose stated
purpose is to configure the resolver to use the servers provided via
DHCP/PPP, then yes, I expect it to do just that.

Yes, it is. It may very well be that your provider would like you to
forward your DNS traffic to their resolvers to improve latency (via
caches) and reduce their own traffic. They might have opted you in.

I might agree to that. resolvconf mixes both concerns, but then using
resolvconf to map /etc/resolv.conf to 127.0.0.1 is a rather boring
exercise and you might just edit the file. So the primary purpose of
resolvconf is configuring the local resolver and make it forwarding.

I used to do so. Meanwhile I changed most mobile systems to
systemd-resolved.

We disagree.

We disagree.

I also reached out to other committee members and the replies go into
the same direction. Installing resolvconf kinda implies an intention to
run a client system (with forwarding). Perhaps the package description
of resolvconf could be enhanced, but we feel it does what it should be
doing.

So the good thing is that we now got to the bottom of the disagreement.

Given the replies from other committee members, I suggest that if this
were coming to a vote the expected outcome would be declining to
overrule the unbound maintainer.

Do you want to present any further arguments (that we have not seen yet)
in favor of your position?

Helmut

Hello Helmut,

Thank you for the clear feedback.

 > So from this point of view, unbound should not enable the resolvconf
 > hook by default.
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125411#17 )

So the committee is now declining to overrule a maintainer who actually
changed his mind and agreed with me. This is unreal.

Regarding the argument about the server provider:
My provider did not bundle Debian with unbound.
I installed unbound myself.
What they did provide was a DHCP configuration, which I later modified
to use the local resolver. The resulting forwarding behavior was therefore
NOT the consequence of a provider choice, but of Debian’s default
interaction between DHCP-related packages and Unbound. As discussed.

I am very concerned that the privacy and safety risks were not considered
an absolute priority. Silent DNS forwarding is not a minor inconvenience.
Maybe I didn't say it clearly enough:
In some countries, DNS leaks can get people killed. In real life.
I expected this to weigh heavily in the decision.
If not outweigh any other consideration.
But this human factor doesn't seem to even have been considered.
I surely didn't expect any technical consideration to take precedence
over both user safety and privacy.

More broadly, this sets an unfortunate precedent.
Silent behavioral changes between packages erode trust in the system.
In my case, this affected a production server and resulted in a
real-life issue,
despite following a simple well-documented unbound deployment process.

I would bet most affected server admins didn't even notice they were
affected by this silent change. Because it's silent...

Users expect packages to do what their description says, not to be altered
by unrelated packages they (more often than not) didn't consciously choose.

So maybe you should change Unbound's description to be more accurate:
 From man "Unbound DNS validating resolver 1.22.0."
To "Unbound DNS validating resolver, except if you use DHCP - 1.22.1."
Or "Unbound sometimes DNS validating resolver 1.22.1."
Or "Unbound DNS validating resolver but plot twist, you have to be a quite
experienced admin and reverse engineer your whole system to make sure
it doesn't stab you in your back and be a dumb resolver instead - 1.22.1."

I have no further technical arguments. And kind words are hard to find.
It is absurd that I even have to argue about this.
And even more absurd that a committee can be so disconnected...
from reality.

I will stop using Unbound in its current state.
Because I can't trust it anymore.
That's what anti-user decisions do:
make otherwise good software avoided, sometimes even hated.
(makes Debian kinda look like MS products now... what a shame)
I will surely stay alert for similar landmines in the Linux ecosystem.

Hopefully this last attempt will help you see what is obvious to me.

The decision is yours to make.

Thanks for your time.

LRob

I think there's some confusion here. Helmut has explained that the
current state of affairs is ustifiable, but this is not a requirement
from the committee that the maintainer retain that behaviour. Where
there's ongoing conversation we will express opinions, but in general we
won't attempt to impose an outcome on those conversations.

Right now I think there's a reasonable argument that the resolvconf
behaviour is, well, the entire point of resolvconf. I also understand
that having an installed package change the effective behaviour of
another package may result in unexpected outcomes, and the very worst
case there may be extremely bad. At this stage we've seen a limited
discussion from a small set of people, and I think for the committee to
actually take action we'd need

1) An opportunity for broader discussion to ensure we have a full set of
perspecties to take into account
2) An explicit statement from a maintainer that they will not do
anything

Until that there isn't really anything to overrule and also there isn't
enough information for us to reach a fully informed decision.

<snip>

I understand your frustration here, but please remember that Debian is a
community project that aims to meet an extremely large range of user
needs and requirements. Personally, as someone working in the security
industry, I have a lot of sympathy for your position - but right now we
do not have enough information to assert that the only way to improve
things is to overrule a maintainer.

The tone that you've adopted throughout this discussion is not helpful
in getting us to the point where we can reasonably say that all relevant
stakeholders have felt able to express their position. Debian is
fundamentally a collaborative enterprise, and cases where we have to
overrule maintainers tend to indicate that that collaborative process
hasn't gone as well as it could. Please keep that in mind in future.

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?

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.

Thanks for your answers

Helmut

Thank you Matthew for your perspective.

Regarding your two conditions:

1) Broader discussion

I agree this is needed. I note that some of the committee's deliberation
happened privately, which may have limited the range of perspectives
considered so far. Would it be possible to move the remaining discussion
to a public venue to gather wider input?

2) Explicit maintainer statement

In the original bug #1124968, Michael wrote:

 > I wont argue any more here, there's no point.
 > If you feel the default [...] should be changed, please ask the
security team or a technical committee.

This read as a clear refusal to act. However, Michael's subsequent
message in this thread (#17) concluded that "unbound should not enable
the resolvconf hook by default," aligning with my position. His current
stance is therefore unclear, and I think hearing from him directly would
help everyone.

Michael, could you clarify your current position?

One additional point

I'd like to raise a question I haven't seen addressed: what was the
original justification for enabling this hook by default? The script
itself notes it was disabled for several releases before being
re-enabled. If there was no broad user demand for this change, while
introducing the privacy and security concerns discussed here, that would
be a strong argument for reverting to the previous default.

I hear Matthew's point about collaboration, and I appreciate the
committee's time on this. I'll keep my contributions constructive going
forward.

LRob

Support LRob <debiantracker@lrob.fr> writes:

You've raised this repeatedly in this discussion, so I just wanted to
note, as an uninvolved bystander, that I think you are misreading
Michael's message. I read his message #17 at the time, and still read it
now, as attempting to clarify *your* position for Helmut so that Helmut
had an accurate understanding of the dispute, not as a change in *his*
position. That's why that sentence starts with the phrase you are omitting
in your quote: "So from this point of view".

correction.

That said, a direct confirmation from Michael would still help establish
where things stand, since his position is central to Matthew's second
condition.

On a broader note: I've raised privacy and security concerns several
times in this thread, but I haven't seen them directly addressed, except
perhaps by Matthew, who expressed sympathy for my position. I'd
genuinely like to understand how the committee weighs these against
other considerations. Is there a shared framework for evaluating such
tradeoffs in Debian?

I'm also wondering whether I initially directed this to the right place,
given that my primary concern is security rather than a purely technical
disagreement.

LRob

Support LRob <debiantracker@lrob.fr> writes:

Again, just a bystander here and not a member of the technical committee,
but what I's say is that I'm sympathetic but I also found the argument
that this is the purpose of resolvconf to be persuasive.

It seems fairly clear from your previous messages that you do not want
what resolvconf does and do not want the package installed and did not
realize that it was installed or what it would do. I don't like that you
were surprised, and I think that indicates a problem somewhere, but it's
not obvious to me that it's a problem with unbound, as opposed to a
problem with however you got resolvconf installed in the first place when
you clearly didn't want it. Or at least did not know that you should
remove it for this use case.

I *think* removing resolvconf would resolve your problem, and maybe a
better place to put effort would be to make sure people know that this is
what resolvconf does and that they should remove it if they don't want
this behavior. I personally have used resolvconf in the past and didn't
know that it would do this, even though in retrospect it's possible to
derive that information from the package description, so it does seem
reasonable to me that there's room for improvement there.

I'm very sympathetic to the argument that most laptop users want
resolvconf and want this behavior since otherwise their computer is not
going to work the way they expect (captive portals are very common), so I
think the behavior provided by the current configuration of unbound plus
resolvconf is valuable, but may need to be better targeted. (It's fairly
important to get captive portals working in that use case because when
they don't, it may not be possible for the user to install a package to
fix the problem, since by definition they don't have network when the
captive portal is not working.)

This is the right place.

Hi Support (2026.02.05_14:57:58_+0000)

The committee have had some private discussion on the matter (as we
always do), but this is just sounding out thoughts, coordination, etc.
not deliberation on a decision.

I think all the points we discussed were reflected in the bug already.
We don't all feel the need to repeat what has already been clearly said.

Stefano

Hi Russ (2026.02.05_19:13:37_+0000)

I think an unbound configuration to forward requests for captive portals
could be tightly targetted to the known domains used by web browsers and
desktop environments. That's what I'd expect, to solve that specific
problem.

The approach taken by unbound + resolveconf does help with captive
portals. But more than that, it makes unbound work the way that a
resolvconf user would probably expect. Do DNSSEC validation, and forward
everything else to the upstream resolvers.

As a user, this is not the way I'd expect unbound to work to catch
captive portals. But I wouldn't have resolveconf installed if I was
expecting unbound to be acting as a recursive resolver for me.

Stefano

Also, I will note "private" here is not the right word. You can find our
last meeting's minutes at

https://meetbot.debian.net/debian-ctte/2026/debian-ctte.2026-02-04-19.00.html

including full irc logs (linked).

   paultag

If I were an unbound user, I would NOT expect it to ship resolvconf
integration by default precisely because it is described as a recursive
resolver.

I would probably expect the resolvconf integration to be tied to the
recursive vs forwarding toggle, but definitely would not expect either
to be default.

Running a recursive resolver does not necessarily mean wanting to use it
locally (e.g. there may be valid reasons to run it to provide the
service to other hosts).

Having resolvconf installed is not an opt-in to such functionality on
its own. It simply means "I don’t want software to randomly overwrite
each other's entries in /etc/resolv.conf", nothing more.

Hi,

Hello,

First of all, sorry for the delayed response.
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.

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.

Hello LRob, Michael and Andrej,

LRob referred a disagreement with unbound maintainer Michael about the use of
the resolvconf hook to the CTTE. The resulting discussion made it clear that
the issue was not well-researched by the submitter beforehand. Several angles
and options for resolving the disagreement evolved. For instance, not
installing resolvconf would provide the semantic sought by the submitter. In
particular, the purpose of the resolvconf hook is ambiguous in our view.  The
resolvconf README states:

| Local DNS cache programs must be able to arrange for nameserver
| addresses supplied by interfaces to be passed to them for use as
| forwarders.  The libc resolver should use any local DNS caches that
| are available.

It also mentions how this is intended to apply to bind9 (which by default is a
recursive resolver).

| * To make bind9 use nameserver addresses supplied by other sources as
|   addresses of forwarders, ...

On the flip side, resolvconf maintainer Andrej stated in the bug discussion:

To us, this makes it evident that the available documentation of the hook
interface is not clear enough to determine whether unbound's use is intended.

We believe that there is a constructive path forward in clarifying how
recursive resolvers should interface with resolvconf, but this is design work
rather then mediating a disagreement between developers. As such it falls
outside the powers and responsibility of the CTTE.

We therefore hand the issue back to the submitter and the relevant package
maintainers without issuing a decision. Please work together towards clarifying
the purpose of the hook interface and making resolver implementations adapt
their hooks if necessary.

If you end up running into an unresolvable disagreement in that process, you
may refer the issue back to the CTTE, but for now we expect that more work is
invested in resolving the matter cooperatively. In particular, consistent
behavior between packages is a key design aspect. Establishing such
consistency, requires research that we have not seen in the discussion.

Helmut for the CTTE