Stub zone behavior

The Unbound configuration I was using on FreeBSD 10 last year is not behaving
the same way on FreeBSD 11. Maybe I overlooked something.

My goal is to have a caching resolver that forwards to Comcast or Google's
nameservers for all but a handful of DNSBL zones, namely multi.uribl.com,
dnsbl.sorbs.net, iadb.isipp.com, and zen.spamhaus.org.

This was easy to set up in BIND by just defining the forwarders for those
zones as an empty set, but I was advised here last year that in Unbound, to
get that behavior, I have to set those up as stub zones with hard-coded
authoritative nameservers. So I did that, creating files like
/var/unbound/conf.d/multi.uribl.com.conf, containing:

stub-zone:
  name: multi.uribl.com
  stub-host: hh.uribl.com.
  stub-host: aa.uribl.com.
  stub-host: bb.uribl.com.
  stub-host: cc.uribl.com.
  stub-host: dd.uribl.com.
  stub-host: ee.uribl.com.
  stub-host: ff.uribl.com.
  stub-host: gg.uribl.com.

/var/unbound/forward.conf looks like this:
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
        name: .
        forward-addr: 75.75.75.75
        forward-addr: 75.75.76.76
        forward-addr: 8.8.8.8

After a 'service local_unbound reload' it worked great; in response to
'host -tTXT test.uribl.com.multi.uribl.com' I would get the "permanent
testpoint" response instead of a "Query Refused" message referencing my
ISP's server.

For some reason, this technique is not working on a fresh installation
of FreeBSD 11-STABLE, running the Unbound 1.5.10 that it comes with.
I still keep getting the Query Refused messages. What did I miss?

Thanks,
Mike

Hi Mike,

The stub- and forward-zone clauses look fine. You could run
"unbound-control list_stubs" to verify that the stub from your config is
loaded into Unbound.

Regards,
-- Ralph

Interesting; thanks. It looks like my stub configs are not being read.

After poring over my config files again, now I see the problem. It was a silly
mistake; I didn't name my stub zone config files correctly. They need to end
with .conf in order to be picked up by the
"include: /var/unbound/conf.d/*.conf" line in unbound.conf.

I fixed the names and that took care of it, although now for some reason when
I do the "unbound-control reload", I get an extra message: "error: cannot
chdir to directory: (No such file or directory)"

It doesn't seem to hurt anything, but does it indicate a problem on my end?
The message apparently originates in util/configparser.y when processing
includes.

Hi Mike,

I am.

# cd /var/unbound/
# grep -r chroot .
./unbound.conf: chroot: /var/unbound
# unbound-control reload
ok
Dec 23 09:11:27 chilled unbound: [14103:0] notice: Restart of unbound 1.5.10.
Dec 23 09:11:27 chilled unbound: [14103:0] error: cannot chdir to directory: (No such file or directory)
Dec 23 09:11:27 chilled unbound: [14103:0] notice: init module 0: validator
Dec 23 09:11:27 chilled unbound: [14103:0] notice: init module 1: iterator

Hi Mike,

I meant unbound's working directory, configurable using the "directory"
config element.

Regards,
-- Ralph

Ah. Well, directory and chroot are the same, the default of /var/unbound.
It's a mystery.

Hi Mike,