inconsistent forward-zone behavior between config files, unbound-control

Mike Brown mike at
Wed Sep 23 16:11:59 UTC 2015

On Wed, Sep 23, 2015 at 11:47:31AM +0200, W.C.A. Wijngaards via Unbound-users wrote:
> Not a clue about comcast or uribl, but your unbound.conf looks weird:
> > # cat /var/unbound/conf.d/uribl.conf forward-zone: name:
> > forward-host:
> > 
> This entry creates a loop, where unbound has to lookup
> to lookup, and to do that it has to lookup
> ...  And that causes it to fail.
> Also is a website, and unbound wants nameservers (the
> right hand side of the dig NS lookup).
> To remove the endless loop you can type IP adresses (with
> forward-addr: ip), but in this case, uribl has nameservers that do not
> cause a loop:
> forward-host:
> forward-host:
> ..
> forward-host:
> Another point, it should be a stub-zone, because those are
> authoritative servers that you are listing in the config.  Use
> stub-zone: and stub-host: in the uribl.conf file.

Thanks, W.C.A.

For BIND, I was advised to handle DNSBL zones simply like this, and I even put 
this advice in the Spamassassin wiki, since it worked for me:

  zone "" { type forward; forward first; forwarders {}; };

Presumably, and correct me if I'm wrong, for any lookup in the 
domain, BIND just bypasses the default forward and instead forwards to the 
root nameservers and recursively resolves from there, along the way learning 
about and temporarily caching the current list of aa,bb,.., 
servers and their probably randomized order.

To instead be hard-coding a certain list of those nameservers in a certain 
order feels risky, given that they seem to intend for some flexibility in what 
servers are available and what order they should be in.

Is it not possible to do something similar in Unbound?

More information about the Unbound-users mailing list