[Unbound-users] use of unbound's interface-automatic option.

Sat Feb 14 20:59:07 UTC 2009

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 user
> queries.  It does not affect the outgoing queries to authority  
> servers.
>
> On your machine I think you should not set the outgoing interface (use
> default, 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 of
> protection against spoofing.  It is uncommon, but the reason I made  
> this
> is because it is one of the very few means to get extra anti-spoofing
> randomness.  That is why support is there - for the paranoid (or  
> people
> with 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 this
> email help you get things working; or do you need more support from  
> the
> unbound 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.
					<woods at planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090214/fbb2911f/attachment.bin>