With recursion turned off you are probably already essentially a waste of the attacker's resources (you send tiny
REFUSED responses instead of the big response to the
ANY query they attempted, so no amplification anymore), they just haven't noticed yet that they probably would get much more out of using some other wide-open recursors instead. It might be that the flood of queries will end on its own soonish.
As you noted, the built-in mechanism in BIND is Response-Rate Limiting, which can be tweaked in different ways involving sending truncated responses to trigger real clients to switch to TCP (useful for normal responses, but you are already sending
REFUSED) or dropping responses outright. It is however designed to still keep the service as available as possible, which will mean not completely shutting anyone out.
A good point from the BIND manual's RRL section (which is also applicable to any other solution which involves dropping responses) is how dropped responses on an authoritative server can make you an easier target for cache poisoning attacks:
NOTE: Dropped responses from an authoritative server may reduce the difficulty of a third party successfully forging a response to a recursive resolver. The best security against forged responses is for authoritative operators to sign their zones using DNSSEC and for resolver operators to validate the responses. When this is not an option, operators who are more concerned with response integrity than with flood mitigation may consider setting slip to 1, causing all rate-limited responses to be truncated rather than dropped. This reduces the effectiveness of rate-limiting against reflection attacks.
There are other options, such as dnsdist which you could place as a reverse-proxy in front and have it dynamically refuse or drop clients that exceed your acceptable query rate. One good thing here is that dnsdist, as the name suggest, is DNS-aware and quite flexible. So you would have the option to eg aggressively limit
ANY queries alone and/or rcode
REFUSED, while not affecting other queries (not affecting other queries may be based on regular rules instead).
There's also, as was noted by Michael fail2ban which could dynamically add firewall rules to block IPs based on excessive log entries. This is a bit blunt in comparison but would certainly be effective from the perspective of limiting traffic and log spam, but completely drops traffic once it triggers.
Again, for any option that involves dropping queries, do keep the above note on cache poisoning in mind.