Maintained by: NLnet Labs

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

Greg A. Woods
Sat Feb 14 02:02:16 CET 2009


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.

The first hurdle was finding that the following patch is necessary
(against 1.2.1) (FYI, I have do-ip4 but not do-ip6 set):

--- services/listen_dnsport.c.orig	2008-09-10 11:23:01.000000000 -0400
+++ services/listen_dnsport.c	2009-02-13 18:38:33.000000000 -0500
@@ -602,8 +602,8 @@
 	if(!do_ip4 && !do_ip6) {
 		return NULL;
 	}
-	if(do_auto && (!do_ip4 || !do_ip6)) {
-		log_warn("interface_automatic option does not work when either do-ip4 or do-ip6 is not enabled. Disabling option.");
+	if (do_auto && !(do_ip4 || do_ip6)) {
+		log_warn("interface-automatic option does not work when either do-ip4 or do-ip6 is not enabled. Disabling option.");
 		do_auto = 0;
 	}
 	/* create ip4 and ip6 ports so that return addresses are nice. */


(If I'm not mistaken this is the second similar logic bug I've found the
unbound code -- I'd go looking for more but I'm as apt to make identical
mistakes so someone better at reading logic expressions than I and the
authors should have a closer look at the rest of the code!)


The second hurdle is that I'm running on NetBSD-4.x and the first thing
in the log is a stream of errors starting with:

Feb 13 18:47:38 once unbound: [18958:0] info: start of service (unbound 1.2.1).
Feb 13 18:47:43 once unbound: [18958:0] notice: sendmsg failed: Invalid argument
Feb 13 18:47:43 once unbound: [18958:0] notice: remote address is 204.92.254.2 port 62639



I'm guessing this is because either the necessary support for this
option isn't really in NetBSD-4, or it hasn't been ported to work with
NetBSD yet.

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.

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.

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:

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

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.

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.

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

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

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.

-- 
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852   VE3TCP    RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>       Secrets of the Weird <woods at weird.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20090213/77e407f0/attachment.pgp>