On 21/09/2011 18:28, Steve Jenkins wrote: 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 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
