Unbound does not use "outgoing-interface" for IPv6 TCP requests

Unbound
1

Hi.

My unbound.conf contains multiple outgoing interfaces:

outgoing-interface: 85.10.240.249
outgoing-interface: 85.10.240.250
outgoing-interface: 2a01:4f8:130:6321::2:0
outgoing-interface: 2a01:4f8:130:6321::2:1

Unbound uses the configured v4 addresses for both UDP and TCP requests
and v6 addresses for UDP. IPv6 TCP queries are sent with the host's
default address, though:

2001:470:1f0b:fde::2.43958 > 2001:500:49::1.53: SWE, [...]
2001:470:1f0b:fde::2.43958 > 2001:500:49::1.53: P, [...] DNSKEY? InfO. ar: . OPT UDPsize=65432 OK (33)

Does anyone else see that behaviour?

I looked at outside_network_create() and outnet_tcp_take_into_use() in
services/outside_network.c but didn't see anything obvious.

Unbound version is 1.4.7/svn rev. 2274

Hauke.

2

* Hauke Lampe:

Does anyone else see that behaviour?

I saw it on IPv4, too, it's not IPv6-specific at all. I tried to fix
it once, but IIRC, it required changes to library interfaces, so I
gave up. 8-/

3

Hi Hauke, Florian,

So right now unbound uses the OS. It creates a TCP socket and connects
to the destination. The OS then decides what interface to send this
from. Your route table is consulted by the OS to decide this.

It does not use the configured outgoing interface for TCP.

In the interest of prevention of feature bloat, I would like to ask,
apart from thanking you for reporting the oddity, if such code is really
necessary? (and would random sampling then be sufficient?)

Best regards,
   Wouter

4

I think it should be able to do so. People who bind/listen unbound to one IP on
their multihomed machine do have an expectation of this, and will likely put
firewall rules in place to limit to that one IP. unbound would currently not work
in such a setup.

Paul

5

So right now unbound uses the OS. It creates a TCP socket and connects
to the destination. The OS then decides what interface to send this
from. Your route table is consulted by the OS to decide this.

All unbound should need to do is to use the ip of the desired interface
rather than 0 as the source ip. The OS should then Do The Right Thing.

-JimC

6

* W. C. A. Wijngaards:

In the interest of prevention of feature bloat, I would like to ask,
apart from thanking you for reporting the oddity, if such code is really
necessary?

If you're multi-homed and the uplinks are semantically different,
being able to set the source IP address is basically a requirement for
correct operation.

7

> In the interest of prevention of feature bloat, I would like to ask,
> apart from thanking you for reporting the oddity, if such code is really
> necessary?

If you're multi-homed and the uplinks are semantically different,
being able to set the source IP address is basically a requirement for
correct operation.

Agreed. Simply letting the OS choose the address based on destination/
outgoing interface is *not* enough for a name server.

Look at what for instance BIND is doing. And CNS. And several others.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

8

Hi Wouter.

In the interest of prevention of feature bloat, I would like to ask,
apart from thanking you for reporting the oddity, if such code is really
necessary?

Unbound's behaviour was quite unexpected and in my case caused Unbound
to use a tunneled IP address instead of a direct route. Although it
works for me, I think Unbound should use "outgoing-interface" for TCP, too.

(and would random sampling then be sufficient?)

TCP offers enough spoof protection, so even using only the first
configured address would be sufficient, IMHO.

Random sampling would be more consistent with UDP behaviour, though.

Hauke.

9

Hi Florian,

10

Hi,