Maintained by: NLnet Labs

[Unbound-users] per-forwarder source address?

Michael Tokarev
Sun Mar 25 09:28:11 CEST 2012

On 23.03.2012 19:09, lst_hoe02 at wrote:
> Zitat von Michael Tokarev <mjt at>:
>> Hello.
>> I've a multi-homed host here, in DMZ, with unbound
>> running on it.  The internal network has its own
>> auth nameservers and its own domain names.  The
>> host in question has regular externally-accessible
>> IP addresses (several) and 192.168.* addresses for
>> access of internal LAN.
>> And the issue I'm seeing is - unability to configure
>> "regular" outgoing address (outgoing-interface) which
>> should be one of these external IPs, together with
>> using one of internal addresses when contacting the
>> forwarders.
>> I wonder if something like this:
>> forward-zone:
>>  name: ""
>>  forward-address at 53:
>> may help?  Or alternatively, even an additional
>> section like
>> server:
>>  name: "internal-resolver"
>>  address: at 53
>>  outgoing-interface:
>> forward-zone:
>>  name: ""
>>  forward-server: internal-resolver
>> is worth to implement?
>> The same applies to nsd but at different "angle",
>> I'll post a separate message there...
>> Thanks!
> Not sure if i have understand it, but looks like a similar issue here:

Yes this is closely related.  The bottom line from that post:

"This is really the OS route table job.  Unbound lets the OS
choose, using a wildcard address."

I can buy this, and this is how I actually solved my issue
which prompted me to write the initial question.

One interesting or fun (depends on your viewpoint) 'technique'
I've seen in use before was to assign two (or more) addresses
to a host, make one to be the "default" but bind all services
running to another.  This way, any packet originating from the
"defaul" address is a strong indicator that something is not
right (ie, the host is "0wned").  That's where letting the OS
to choose is not the right thing to do ;)

In any way, current "outgoing-address" directive is at least
misdesigned.  It is not a property of a zone, it is a property
of a server to which unbound should connect to (regardless of
zones), or, maybe, of a zone+server combination.  That's why
I asked about opinions (not implementation!) for making a
separate "server" section or other ways to solve this

Thank you!