A former coworker and I played around with this. He was red team, I was blue. It was a fun experiment. Stopping this with some of the corporate firewalls is easy but I wanted to see if I could break it with rate limiting. Unbound has really nice controls for IP/domain rate limiting but it's a double edged sword. Iodine can be broken with rate limiting but then poorly coded applications also break. One would have to take on the challenge of fixing all applications to obey TTL's and it turns out that is quite a monumental challenge. This also required increasing the min TTL of requests and that has an impact on AWS EC2 instances that are designed around a 5s TTL. In the end all I could come up with was a way to alert on an IP exhibiting this behavior and send a syslog message with the IP and just hope someone responds to it quickly enough which is a very sub-optimal solution. The expensive corporate firewalls would just block that specific IP for a period of time and also send an alert which I suppose could have been done with a wrapper to null route the specific IP but then false positives from poorly coded applications would result in outages. At least with the corporate firewalls people could point the finger at them and not me. It was still fun nonetheless.
If anyone is curious why we were going through this exercise, all 50k+ servers had Unbound running locally to take the load off the edge recursive servers and handle upstream fail-over faster. Unbound is remarkable in the data-center for this purpose.