[blumentopf]

Ugh, so public resolvers are flooded with requests? Wouldn't it make much more sense to set up a local caching resolver like unbound and feed your queries to it? It would be much more considerate towards the public resolvers and also use less of your own bandwidth.

[matt_wulfeck]

There are valid use cases for this. For example, web crawling needs to do millions of resolutions one time which completely nullifies the need for a cache.

[blumentopf]

For this to be correct, all records to be resolved would need to have completely disjunct labels from the root down. Which they cannot if they are indeed in the millions.

[blechschmidt]

I have not yet managed to setup a single local recursor, such as PowerDNS recursor, to deliver the same performance as the list consisting of multiple open resolvers, although bandwidth does not seem to be the limiting factor. Testing with dnsperf, the best result I am currently getting is about 6,000 resolves per second with bind, for PDNS the figure is even lower for some reason. I will have to dig a bit deeper in order to find the reason for that cap.

[blumentopf]

I'm not surprised at all that BIND performs poorly, look at those graphs (granted this is for authoritative servers, but says a lot about BIND's performance in general): https://www.nlnetlabs.nl/blog/2013/07/05/nsd4-performance-me...

I'd stick with Unbound. There are a lot of knobs to fiddle with in the config. Be sure to compile against libevent so that you can use the highly scalable epoll as a backend (assuming you're on Linux). Turn up all the limits for cache size etc. Disable DNSSEC validation if you don't care about spoofed records. Ask on the mailing list if you need help, Wouter and his colleagues are very nice and respond very quickly.