On 23.03.2012 19:09, [email protected] wrote: > Zitat von Michael Tokarev <[email protected]>: > >> 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: "foo.example.com" >> forward-address 192.168.1.2@53:192.168.1.1 >> >> may help? Or alternatively, even an additional >> section like >> >> server: >> name: "internal-resolver" >> address: 192.168.1.2@53 >> outgoing-interface: 192.168.1.1 >> forward-zone: >> name: "foo.example.com" >> 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: > > http://unbound.net/pipermail/unbound-users/2009-February/000448.html
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 misdesign. Thank you! /mjt _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
