+1, this is a critical security bug.
On Tue, Jan 13, 2026 at 6:19 PM LRob <[email protected]> wrote:
>
> I understand the captive portal concern, but I respectfully disagree
> with the current default.
>
> The current default breaks the principle of least surprise and the
> package's own description as a "recursive resolver".
>
> For a reminder, the package's own description:
>
> "NAME
> unbound - Unbound DNS validating resolver 1.22.0.
> [...]
> DESCRIPTION
> Unbound is a caching DNS resolver.
>
> It uses a built in list of authoritative nameservers for the
> root zone (.), the so called root hints. On receiving a DNS query it
> will ask the root nameservers for an answer and will in almost all cases
> receive a delegation to a top level domain (TLD) authoritative
> nameserver. It will
> then ask that nameserver for an answer. It will recursively
> continue until an answer is found or no answer is available (NXDOMAIN).
> For performance and efficiency reasons that answer is cached for a
> certain time (the answer's time-to-live or TTL). A second query for the
> same name will
> then be answered from the cache. Unbound can also do DNSSEC
> validation.
> [...]"
>
>
> 1. SILENT PRIVACY BREACH: Users installing a "recursive resolver"
> have a reasonable expectation of... recursive resolution.
> Silently forwarding all queries to a third party (ISP, hosting
> provider) without any warning is a privacy violation.
> In some countries, this can have dramatic consequences.
>
> 2. WORSE THAN BROKEN: A non-working DNS is immediately visible and
> fixable. A silently forwarded DNS looks like it works, but leaks
> all queries to an upstream resolver. Users who specifically chose
> unbound for privacy are unknowingly exposed.
>
> 3. TARGET AUDIENCE: Who installs unbound on a laptop for wifi hotspots?
> The typical unbound user is running a server or a privacy-conscious
> desktop with stable connectivity. Captive portals are an edge case
> for this package's actual userbase.
>
> SIMPLE MIDDLE GROUND SOLUTION:
>
> - Default to disabled (recursive) as before
> - Document clearly how to enable forwarding for captive portal scenarios
> - Or: detect if running on a server (no NetworkManager?) vs desktop
>
> Thank you
> LRob
>
> On 1/8/26 8:17 AM, Michael Tokarev wrote:
> > If we ignore DHCP-provided nameservers and always perform recursive name
> > resolution, we'll have non-working internet connectivity in common wifi
> > areas where captive portals are in effect.
> >
> > If you have stable internet connectivity where you're sure recursive
> > resolution works, you're free to drop execute permissions from this
> > hook, and recursive-only name resolution will work fine for you.
> > For a general case, we need a working internet first, making debian
> > to be unable to connect to the internet by default is wrong, in my
> > opinion.
> >
> > If you disagree and insist on disabling this hook by default, I think
> > a wider discussion is in order.
> >
> > Thanks,
> >
> > /mjt
