On Thu, 5 Feb 2026 19:36:56 +0000 Stefano Rivera <[email protected]>
wrote:
Hi Russ (2026.02.05_19:13:37_+0000)
>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.
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.
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.
--
Cheers,
Andrej
