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
