On 14-Feb-2009, at 5:17 AM, W.C.A. Wijngaards wrote:
Let me state up front that this and also the previous logic you found was exactly the way I meant it.Interface automatic is only meant for when you enable both ip4 and ip6.
Hmm, OK, well I think a better way to express that so that it cannot be as easily misunderstood would be to write:
if (do_auto && !(do_ip4 && do_ip6)) {
print error...
return ...;
}
and omit the (!do_ip4 && !do_ip6) check above it.
That way it reads naturally in English at least: if do_auto and not
both do_ip4 and do_ip6.
I also still don't think the expression you had written would do what you want either.
I further guessed that either ip4 _or_ ip6 would work because of surrounding logic.
The statement above checks that at least one of the two option is enabled suggesting that either will suffice. The one above that even ensures do_ip6 is zero if INET6 is not defined.
Then the statements below the one I changed do different things depending on which option was enabled.
From my inspection of both the code and comments it appears as if it will work for both ip4 and ip6, or just either one. There's no hint whatsoever that it will only work with IPv6.
I now see code in another function called by the one I patched that'll try to complain if it thinks IPv6 is not available, however that apparently doesn't fail on my system even though the kernel does not have IPv6 enabled.
You have to enable IPv6 to have interface automatic work. It uses IPv6 socket options.
Well the logic right below the statement I referred to would use _either_ IPv6 options _or_ plain IPv4 options depending on which options are enabled.
Also the logic in set_recvpkt() that will work for both AF_INET6 and AF_INET and I didn't observe any errors from that function, especially not the one indicating that I would have to disable interface-automatic.
(That function really would be better written as a set of variant functions, only one of which might be compiled and linked, thus avoiding all the messy #ifdefs)
So, I'm still confused -- it looks like there is enough support for this feature to work for IPv4 interfaces alone, at least in the code in unbound.
This maybe why your NetBSD4 errors - if ipv6 is disabled it may reject the IPv6 options.
Well my kernel doesn't have IPv6 compiled into it, but it would appear NetBSD setsockopt() does at least have the right #defines for supporting this feature.
There would need to be more debugging support code added for me to figure out what the error message I noted from the logs actually means.
A note on the side. You can use interface automatic with IPv6 enabled on the box but not on the network. Unbound needs to talk to the IPv6 (dual stack) network stack in the kernel for it ... Simply set do-ip6 to yes (and it'll figure out that the ipv6 network is not reachable).
My kernels don't support IPv6 at all, and normally I don't even compile applications with INET6 or USE_INET6 defined, but in this case the config.h for unbound doesn't really give me any choice. My headers and libraries do appear to support IPv6, but I don't want it in my kernels when I have no IPv6 network to use -- it just confuses the sysadmins.
Aha, you could perhaps use the private-domain: "company.example" and private-address: 192.168.0.0/16 statements to protect. For extra protection.
Yes, I have those configuration items as well. I guess I'll have to restrict queries to the cache too since it will contain both public data and private data. With BIND-8 I used to use ACLs to prevent queries of the private data from all but known addresses. I prefer to leave the public data in the cache publicly accessible even if that also gives the bad guys a bit more of an edge (debugging is still more important to me). However without per-zone ACLs that won't be possible.
Ah! Interface automatic uses the same interface for *replies* to userqueries. It does not affect the outgoing queries to authority servers.On your machine I think you should not set the outgoing interface (usedefault, which is the wildcard address). And fix the route table on the machine to use the correct interface for the correct LAN (if it is wrong).
Ah, OK I see! The wild-card outgoing interface should work then.
You can:
outgoing-interface: 0.0.0.0
Is that going to be any different than not specifying any outgoing- interface?
Yes. If you commission extra IP addresses you can get extra bits ofprotection against spoofing. It is uncommon, but the reason I made thisis because it is one of the very few means to get extra anti-spoofingrandomness. That is why support is there - for the paranoid (or peoplewith IP addresses to burn).
Ah, OK, that makes sense too -- though of course normally one would probably only use a single physical and logical interface but one with multiple IP address aliases configured on it. Otherwise the physical networking gets a bit more complex, and there's also the problem of having multiple Ethernet MACs for the same host (or not being able to, depending on one's hardware).
OK, I would rather not make 'routing' decisions in unbound.
Agreed -- now in the light of a new day I see there's a lot more complication in trying to write portable code to determine the correct source address to use depending on the destination for a query. One would have to interface to the kernel's routing socket to learn which interface would be used, and then effectively cache a representation of the routing table in order to keep performance from sucking too badly, though it still would be far more expensive and complex than just letting the kernel do the source-address assignment.
Does thisemail help you get things working; or do you need more support from theunbound code?
Yes, I've configured the errant server to use 0.0.0.0 for the outgoing replies and all seems to be working properly now.
Thanks very much for your reply!
--
Greg A. Woods; Planix, Inc.
<[email protected]>
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
