Interface: 0.0.0.0 apparently not working

Unbound
1

We have a total of three subnets (let's call them A, B, and C).

Our unbound box has 2 NICs: one with an IP addresses on Subnet A, and
another with an IP address on Subnet B.

We have a number of servers, some connected to subnets A & B, and one
that is connected only to Subnet C.

In unbound.conf, we are using:

interface: 0.0.0.0
interface: ::0

and using access-control: to allow IP ranges on all three subnets.

However, unbound will only answer queries as follows:

1) From servers on subnet A: unbound answers queries made to its IP
address on Subnet A or B.

2) From servers on subnet B: unbound answers queries made to its IP
address on either Subnet A or B.

3) From the server on subnet C: unbound answers queries made ONLY to
its IP address on Subnet A, but does not respond to queries made to
its address on Subnet B.

4) From a remote server on still another subnet (we tested with a
shared host we had shell access to), identical results to case #3
above.

I turned verbosity all the way up to 5 in the logs, and in cases #3
and #4 above, unbound does see the query. It just doesn't respond.

I was able to work around this by commenting out both the interface:
0.0.0.0 and ::0 lines and replace with:

interface: 127.0.0.1
interface: ::1
interface: IP on Subnet A
interface: IP on Subnet B

So I'm glad I was able to work around it, but I'm curious why
interface: 0.0.0.0 didn't work as it should. Any ideas?

Thanks,

SteveJ

2

Hi Steve,

3) From the server on subnet C: unbound answers queries made ONLY to
its IP address on Subnet A, but does not respond to queries made to
its address on Subnet B.

This may be happening because you've configured unbound to listen on
0.0.0.0. What can happen is that the query is directed to address B, and
unbound looks up the answer. It then wants to send the reply, and it
sets the source address to 0.0.0.0. This leaves the decision up to the
kernel, which can set the source address of the response packet to
address A. Your client is probably getting the response packet, but like
any good client, it can't use this response, because it came from an
address different to the one it sent its query to.

4) From a remote server on still another subnet (we tested with a
shared host we had shell access to), identical results to case #3
above.

This is the same as above.

I turned verbosity all the way up to 5 in the logs, and in cases #3
and #4 above, unbound does see the query. It just doesn't respond.

I was able to work around this by commenting out both the interface:
0.0.0.0 and ::0 lines and replace with:

interface: 127.0.0.1
interface: ::1
interface: IP on Subnet A
interface: IP on Subnet B

This works fine, because now unbound is now listening on explicit
interfaces. When it constructs a response packet, it will set the source
address to whichever address it received the query on, so things will work.

So I'm glad I was able to work around it, but I'm curious why
interface: 0.0.0.0 didn't work as it should. Any ideas?

It's all got to do with routing in the kernel, and not unbound.

Regards,

Anand Buddhdev
RIPE NCC

3

Excellent explanation. Thank you. :slight_smile:

SteveJ

4

Hi,

So I'm glad I was able to work around it, but I'm curious why
interface: 0.0.0.0 didn't work as it should. Any ideas?

interface-automatic: yes

Cheers,
Thomas

5

Thanks, Thomas. I enabled this, but it wouldn't work because I'd set
do-ipv6: no. I commented do-ipv6 out and restarted, and now it's
working perfectly. :slight_smile:

SteveJ