Unbound amplification behaviour on SERVFAIL with many forwarders

[info at rickvanderzwet.nl]

Hi,

I am trying to setup unbound as the default nameserver within the 
Stichting Wireless Leiden Community network, yet I am getting 
amplification issues when querying domains with SERVFAIL responses. I am 
using 'test123456789.nl' as example domain (if somebody knows the 
official 'SERVFAIL' test server, I would be happy).


The setup consist of 20+ edge-nodes (those have an internet connection) 
which provide recursive DNS services and are configured like this:
forward-zone:
     name: '.'
     forward-addr: 8.8.8.8
     forward-addr: 8.8.4.4

(Using the vanilla config of dns/unbound port of FreeBSD as base).

Secondly I have access-nodes (those without internet connection), which 
are configured like this:
     forward-zone
         name: '.'
         forward-addr: 172.31.254.1
         forward-addr: 172.31.254.2
         forward-addr: 172.31.254.3
         ...<snip>...
         forward-addr: 172.31.254.48
         forward-addr: 172.31.254.49
         forward-addr: 172.31.254.50

All nodes together make up an distributed network, due to the resilience 
and the nature of the network the access-node indeed has 50 forwarders 
configured [1]

When I issue a request against an access-node, itself will query the 
fastest 'edge-node', since it will receive an SERVFAIL as response, it 
will continue to query the second, and the third, the forth,.... Meaning 
my single request gets asked to all 'edge-nodes' of which all of them 
which all test same question to its uplink providers.

This amplication is a real problem, since we have seen viruses on 
client-devices which basically act like this:
    sh -c 'for N in $(seq 0 10000); do echo drill a$N.test123456789.nl 
@127.0.0.1 \& ; done' | sh -x


Any pointers in how-to limit this amplification behaviour without 
scrubbing the forwarders list?

Best regards,
/Rick van der Zwet


[1] FYI: Previously I used with BIND an small homebrew tool to reshuffle 
the /etc/resolv.conf as such that the fastest DNS server was listed 
first, how-ever I rather like to use unbound, since it much more memory 
friendly and also has the ability to deal with this kind of optimization 
much smarter itself, in which at first glance indeed seems to be the 
case.