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
On 1/14/26 7:58 AM, Helmut Grohne wrote:
Hello LRob,
On Tue, Jan 13, 2026 at 10:56:38PM +0100, LRob wrote:
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.
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?
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.
Classifying resolvconf as unrelated is a stretch.
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)
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.
What are the next steps to implement this change?
I am not yet seeing consensus on this matter.
Helmut
