The /etc/resolvconf/update.d/unbound hook is now executable by default on new installs. This causes unbound to silently forward all queries to upstream nameservers (provided by DHCP/resolvconf) instead of performing recursive resolution starting from root servers. This is problematic for several reasons: 1. UNEXPECTED BEHAVIOR: Users installing a "recursive resolver" expect recursive resolution, not forwarding. The package description says "validating, recursive, caching DNS resolver" - not "forwarder". 2. PRIVACY LEAK: All DNS queries are sent to upstream resolvers (e.g., hosting provider's DNS) instead of being resolved directly. Users setting up their own resolver often do so specifically to avoid this. 3. CACHE POISONING EXPOSURE: The upstream resolver's stale cache can override authoritative data. In my case, a domain migration was invisible for hours because Hetzner's resolvers had cached old NS records, despite authoritative servers being correctly updated. 4. DNSSEC ISSUES: As noted in the hook's own comments, this can break DNSSEC validation if upstream doesn't support it properly. 5. SILENT FAILURE: There is no warning during installation or in logs that unbound is operating as a forwarder rather than a recursive resolver. The hook script itself acknowledges these issues: > "This hook can be problematic, especially if the upstream nameservers > do not perform DNSSEC validation correctly." Yet it is now enabled by default. SUGGESTED FIX: - Default to disabled (chmod -x) as it was in previous releases - Or add debconf prompt asking user's preferred mode - Or at minimum, log a warning when forwarding is active WORKAROUND: chmod -x /etc/resolvconf/update.d/unbound unbound-control forward off
Control: tag -1 + wontfix 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
Control: tag -1 + wontfix 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
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
+1, this is a critical security bug.
I wont argue any more here, there's no point. If you feel the default (and this really is the default, which is trivial to toggle if you know your environment) should be changed, please ask the security team or a technical committee. My only argument is that the package should not be broken in a typical user environment. With your proposed default, the package becomes out of the box and needs tweaking to work. In my view this is unacceptable, be it critical security hole or not critical. The defaults can't suit everyone, hence there's a trivial way to flip the default. Thanks, /mjt
"Becomes BROKEN out of the box". Thanks, /mjt
Technically, it IS broken out of the box right now: Current defaults defeat Unbound's whole purpose of recursion, while leading to out of the box security issues. I only see downsides and problems with these defaults. I'll escalate to the technical committee as suggested. Thanks, LRob