Maintained by: NLnet Labs

Stub zone behavior

Ralph Dolmans
Wed Dec 21 14:12:36 CET 2016


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

On 21-12-16 12:35, Mike Brown via Unbound-users wrote:
> 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
>