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

[Mike Brown]

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:
> > multi.uribl.com forward-host: multi.uribl.com
> > 
> 
> This entry creates a loop, where unbound has to lookup multi.uribl.com
> to lookup multi.uribl.com, and to do that it has to lookup
> multi.uribl.com ...  And that causes it to fail.
> 
> Also multi.uribl.com is a website, and unbound wants nameservers (the
> right hand side of the dig multi.uribl.com 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: aa.uribl.com.
> forward-host: bb.uribl.com.
> ..
> forward-host: hh.uribl.com.
> 
> 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 "multi.uribl.com" { type forward; forward first; forwarders {}; };

Presumably, and correct me if I'm wrong, for any lookup in the multi.uribl.com 
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,..,hh.uribl.com 
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?