Per-forwarder source address?

Unbound
1

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!

/mjt

2

Zitat von Michael Tokarev <mjt@tls.msk.ru>:

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!

/mjt

Not sure if i have understand it, but looks like a similar issue here:

http://unbound.net/pipermail/unbound-users/2009-February/000448.html

Regards

Andreas

3

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 :wink:

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

4

Any comments on this? I can try to implement it
but I've no idea if this is considered useful at
all. To me it is - obviously - useful :wink:

Thanks!

/mjt

5

Any comments on this? I can try to implement it
but I've no idea if this is considered useful at
all. To me it is - obviously - useful :wink:

I use unbound since years in may strange setups.
But never noticed wrong souce addresses as a problem.
That's a point I always rely on the selection algorithm implemented in the os.
(but it's always linux in my case ...)

so -1, sorry
Andreas

6

Any comments on this? I can try to implement it
but I've no idea if this is considered useful at
all. To me it is - obviously - useful :wink:

I use unbound since years in may strange setups.
But never noticed wrong souce addresses as a problem.
That's a point I always rely on the selection algorithm implemented in the os.
(but it's always linux in my case ...)

so -1, sorry
Andreas

So please tell me how to implement the setup I described using
linux routing, without resorting to policy routing.

Thanks,

/mjt

7

You shouldn't *need* policy routing unless you have a very unusual configuration.

For example, if you have:

eth0 192.168.1.2/24
route 192.168.0.0/16 via eth0
eth1 192.0.2.1
route default via eth1

...then, when sending packets to anything in 192.168.0.0/16, the Linux kernel should pick 192.168.0.0/16 as the source address IF the socket is bound to the wildcard address (if it isn't, no amount of fiddling will fix this).

Is this not what you are seeing? Or do you have a different configuration?

Can you share the output of "ip addr" and "ip route"?

8

02.05.2012 13:12, Phil Mayers wrote:
[]

eth0 192.168.1.2/24
route 192.168.0.0/16 via eth0
eth1 192.0.2.1
route default via eth1

No, this is not what I'm after. The example config has been in
the first email whhat started this thread. Here it is again:

Only one eth0, it is a dmz host. This eth0 has 3 addresses
attached, two "external" - one for dns and one for something
else, and one "internal", -- the address used by all internal
networks to access this host.

Default route points to the outside world, using first "external"
IP address. But unbound should use _second_ "external" address
when performing regular queries. So I had to set outgoing-interface
parameter to be the second "external" address. But when accessing
internal networks (for local auth nameservers), it must use the
"internal" address.

Actually we've quite a bit more complex setup, this is just a
simplification if it. The key points are:

1) non-default outgoing-interface which I have to use, which
    sets outgoing address for _all_ queries, and
2) internal networks are inaccessible from that address.

I can use a policy routing rule to change SOURCE address of
packets going from this DMZ host from one of its "external"
addresses to certain list of internal hosts, port 53, but
this is just ugly.

The main question which I tried to ask here, 3 times already,
is -- why we do have global outgoing-interface when everything
can be done using regular routing setup on the host? We either
should drop this parameter, or implement it correctly to be per-
forwarder, as $subject says.

I'm willing to (try to) do the actual implementation, but asked
if we should go the first, simple, route instead.

Thanks,

/mjt

9

Hi Michael,

02.05.2012 13:12, Phil Mayers wrote: []

eth0 192.168.1.2/24 route 192.168.0.0/16 via eth0 eth1 192.0.2.1
route default via eth1

No, this is not what I'm after. The example config has been in the
first email whhat started this thread. Here it is again:

It looks useful, to you, for your complicated setup. This sort of set
up may not be common. It is pretty common in other areas (like zone
transfers for authority servers). It is possible to configure ip
route src things, but this may get very complicated. A code feature
is the alternative.

Only one eth0, it is a dmz host. This eth0 has 3 addresses
attached, two "external" - one for dns and one for something else,
and one "internal", -- the address used by all internal networks to
access this host.

Default route points to the outside world, using first "external"
IP address. But unbound should use _second_ "external" address
when performing regular queries. So I had to set
outgoing-interface parameter to be the second "external" address.
But when accessing internal networks (for local auth nameservers),
it must use the "internal" address.

Actually we've quite a bit more complex setup, this is just a
simplification if it. The key points are:

1) non-default outgoing-interface which I have to use, which sets
outgoing address for _all_ queries, and 2) internal networks are
inaccessible from that address.

- From this description I would think it may be possible to add a line
to the route table for your internal networks? This line would
override the default route for that internal network prefix, and have
"ip route src=.." option set to prefer a particular source address,
and have the same settings as the default route otherwise. Do you
think this could work (and it is not policy based routing, I believe)?

I can use a policy routing rule to change SOURCE address of packets
going from this DMZ host from one of its "external" addresses to
certain list of internal hosts, port 53, but this is just ugly.

Yes, and then source modification sounds like an idea. But if there
is a lack of other people with similar problems, I would not think
this is a feature that should be included in unbound itself (but if
you do create some solution, the src/contrib/ directory could be a
good way to distribute that as an optional part).

The main question which I tried to ask here, 3 times already, is --
why we do have global outgoing-interface when everything can be
done using regular routing setup on the host? We either should
drop this parameter, or implement it correctly to be per-
forwarder, as $subject says.

I'm willing to (try to) do the actual implementation, but asked if
we should go the first, simple, route instead.

Best of luck,
   Wouter