Changing subject line to "Unbound nested forwarder fallback"
On 2025-12-20 19:39:41, mulh wrote:
>> My primary unbound forwards everything, mostly to public dns resolvers.
>> But some sub-domains I need to do recursive resolution directly (ex: RBLs).
>> So I run a second unbound instance for that purpose and the primary unbound
>> forwards those sub-domains to the second unbound instance for resolution.
>>
>> "forward-first: yes" says it'll fall back to normal recursive resolution if
>> forwarding fails. No it doesn't it'll fall back to the next best matching
>> forwarder: (if defined). All the forwarders would have to fail and all
>> would have to have "forward-first: yes" before normal recursive resolution
>> would occur. Would be nice if forwarders allowed exceptions like some of
>> the other features in unbound have.
On 2025-12-22 11:23:50, Stuart wrote:
> I see that too. That sounds like a bug, I don't see anything in docs
> suggesting that a forwarder failure in one forward-zone should fallback
> to a less specific forward-zone (i.e. "."). If that worked, you could
> probably just set forward-addr to a bogus value like 0.0.0.0 and use
> forward-first (though an explicit "do not use forwarder" config would
> be nicer).
Those jumping in, here's a quick summary:
A simplified unbound.conf to show the focus of the issue:
server:
interface: 127.0.0.1
forward-zone:
name: "."
forward-addr: 9.9.9.9
forward-zone:
name: "zen.spamhaus.org"
forward-first: yes
The question is how would the lookup for 25.2.0.192.zen.spamhaus.org.
be handled? The zen forwarder with no "forward-addr" (or using bogus address)
would cause the forwarding to fail, with forward-first set to yes then
there is fallback, what action does the fallback take?
>From "man unbound.conf" the prominent text is:
" forward-first: <yes or no>
" If a forwarded query is met with a SERVFAIL error, and this option
" is enabled, Unbound will fall back to normal recursive resolution
" for this query as if no query forwarding had been specified.
"
" Default: no
To me this is almost saying two different actions:
1) fall back and do normal direct recursive resolution
2) fall back for this query as if the forward-zone is not configured
As much as I would like to see action 1, unbound responds with action 2.
In action 2 since the zen forwarder is ignored, the best match is now the
forwarder for "." (root). So that forwarder is used and not direct resolution.
Spamhaus has their policies and I'd rather use direct resolution instead of
creating an account with them. It's their service, their rules, ok fine.
My solution thus far has been to use two unbound instances.
Unbound1:
server:
interface: 127.0.0.1
private-domain: "zen.spamhaus.org" # allow 127.0.0.0/8 replies
forward-zone:
name: "."
forward-addr: 9.9.9.9 # quad9, nxdomain for malicious domains
forward-zone:
name: "zen.spamhaus.org" # Spam RBL lookups
forward-addr: 127.0.0.1@5353
Unbound2:
server:
interface: 127.0.0.1@5353
# no forward-zones defined
/etc/resolv.conf:
nameserver 127.0.0.1
Obviously the unbound.conf files have many more lines
(ex: access-control, private-address, etc) but the focus
is to forward or not to forward. I'll share the other
lines if there's any relevance. Currently even my interface
lines are different (multiple interfaces) but what I have
shown here best illustrates how the two instances interact
and I used to do it this way when I was running nsd.
My nsd zones (local) are now auth-zones in unbound1.
To answer my own question:
< The question is how would the lookup for 25.2.0.192.zen.spamhaus.org.
< be handled?
Lookup goes to unbound1 which forwards the request to unbound2.
Unbound2 uses direct recursive resolution to resolve dns request.
Unbound2 sends answer back to unbound1.
Unbound1 then replies to the calling program with answer.
I can see the nesting nature of how unbound works that explains
it's behavior with forwarder fallback. I can almost see a paradox
that a later do-not-forward statement could cause.
>From this perspective I won't call it a bug.
I stop using bind years ago, not long after openbsd switch from bind to unbound.
I'm curious but never looked to see how bind handles forwarding.
But I'm not switching back to bind, unbound's local-data can do things I was
never able to figure out in bind. Back in the day I needed to redirect
"google.com" to "forcesafesearch.google.com" but let "*.google.com" resolve
normally, unbound made this trivial with local-data lines.
Thank you Stuart for all your responses here and in other threads.
I know I've mentioned multiple unbounds before and hopefully
this message explains well enough why I use them.
I'm always open to suggestions, comments from anyone, brainstorming is great
learning!
