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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Greg,

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.

You have to enable IPv6 to have interface automatic work. It uses IPv6
socket options.  This maybe why your NetBSD4 errors - if ipv6 is
disabled it may reject the IPv6 options.

Below, I'll go about helping you :-)

Greg A. Woods wrote:
> I've got a setup where I think the "experimental" interface-automatic
> option might prove useful, or even necessary.
> 
> However I have been unable to get it to work.

> So, perhaps I should describe my situation a little more and see if this
> is something I should pursue trying to fix on myself or not.

Interesting.

> I've got a setup with a pair of NetBSD hosts on a small public subnet,
> one being a firewall with NAT for an RFC 1918 office LAN (192.168.0/24),
> and the other being a public Internet-facing server.  Both servers are
> connected to the private LAN, and both run unbound, nearly identical
> configured except for interface addresses, as a service to the private
> LAN.  There's also a second RFC 1918 private LAN (192.168.255/24)
> between the hosts used for backups and administrative purposes.

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).

> They both also run nsd, the instance on the public server answering
> queries for public DNS zones, and the instance on the firewall is
> listening only on a second address (192.168.0.254) on the private LAN
> interface and answering queries only for the private zones.
> 
> The private zones are configured in each unbound instance as stubs like
> this:

Aha, you could perhaps use the private-domain: "company.example" and
private-address: 192.168.0.0/16  statements to protect.  For extra
protection.

> 	stub-zone:
> 	       name: "company.example"
> 	       stub-addr: N.N.N.N	# ns.company.example, for example
> 	
> 	stub-zone:
> 	        name: "office.company.example"
> 	        stub-addr: 192.168.0.254
> 	
> 	stub-zone:
> 	        name: "backups.company.example"
> 	        stub-addr: 192.168.0.254
> 	
> 	stub-zone:
> 	        name: "168.192.in-addr.arpa"
> 	        stub-addr: 192.168.0.254
> 	
> 	stub-zone:
> 	        name: "0.168.192.in-addr.arpa"
> 	        stub-addr: 192.168.0.254
> 	
> 	stub-zone:
> 	        name: "255.168.192.in-addr.arpa"
> 	        stub-addr: 192.168.0.254
> 
> The firewall's rules do address-spoofing protection, amongst other

Thank you for doing BCP 38. :-)

> things of course, and I'm having trouble getting queries to go from the
> server to the nsd instance on the firewall because the firewall's
> anti-spoofing rules are blocking unbound's queries due to them having
> the wrong source address for the LAN segment they're going out on:
> 
> 	bge0 @350:49 b [192.168.255.2],28073 -> [192.168.0.254],domain PR udp len 20 81 IN
> 
> I.e. here was a query from unbound on the server being sent to nsd on
> the firewall (eg. a recursive look-up for office.company.example, for
> example, as per the stub-addr configuration for that zone) using the
> wrong source address.  Sometimes it'll be the admin LAN address,
> sometimes the public address, and (I think) sometimes the correct
> address on the office LAN.

You can set outgoing-interface, but I see that below, I'll keep reading.

> I'm not sure I understand the intent of the "interface-automatic"
> option, but I do know that unbound isn't using the right source address
> for the subnet it's sending to.

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).

> Now I think, IIUC, if I could allow it to use wild-card address for the
> outgoing interface then the OS would set the source address correctly.

You can:
	outgoing-interface: 0.0.0.0

[For the unbound-users public: ::0 is the wildcard address for IPv6.]

> At the moment I have unbound using the following interfaces on the
> server:
> 
> 	interface: 127.0.0.1
> 	# XXX we cannot listen here -- nsd listens here!
> 	##XXX##interface: N.N.N.N	# public IP
> 	interface: 192.168.0.2
> 	interface: 192.168.255.2
> 
>         outgoing-interface: N.N.N.N	# public IP
>         outgoing-interface: 192.168.0.2
>         outgoing-interface: 192.168.255.2
> 
> I'm not sure what trying the wildcard address for outgoing-interface
> will do though because of the sentence in unbound.conf(5) under
> "outgoing-interface" which says "Outgoing queries are sent via a random
> outgoing interface to counter spoofing."

Well, with the above setup, it will choose a random outgoing interface
to send every query from.  It basically expects every outgoing interface
to be able to reach all of the world.

But this is not true for you, because of your firewall rules.  So, I
would simply put the wildcard and let the OS decide.   Or only have the
public IP - which the firewall might let through its rules too?

> The described functionality is completely unhelpful unless you happen to
> be in the very rare situation where global network reachability is
> available on all interfaces.  In the much more common scenario where all

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).

> but one interface serves to connect only to a limited set of subnets the
> right things must be done to ensure queries always have the correct
> source address matching the interface they are transmitted from.

Right.  This is really the OS route table job.  Unbound lets the OS
choose, using a wildcard address.

> Now, if I remember correctly it is possible to set BIND-8 up and running
> in a similar configuration and it will always get the source address
> "right", but I'm not prepared to re-do everything and try.  :-)  I'd very
> much rather get unbound and nsd working.

OK, I would rather not make 'routing' decisions in unbound.  Does this
email help you get things working; or do you need more support from the
unbound code?

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmWmicACgkQkDLqNwOhpPjBKgCbBf8RPYOExfWDH13LRu3Slwe4
/d0AoJ8J/ZMAJjXf0tl174MxbH2sBy8O
=No4O
-----END PGP SIGNATURE-----