One of the things that I mentioned I wanted in a caching nameserver was the ability to forward queries to other nameservers as both recursive and non-recursive queries. A commentator asked, effectively, why you needed to forward recursive queries. As it turns out I did not have a handy answer for this at the time, because I couldn't remember off the top of my head where I'd needed it. Well, I think I've come up with the answer.

Why you need this is zone splicing in upstream caching DNS servers. Suppose that your organization operates some official caching nameservers for everyone inside the organization to query, and further suppose it has a mixture of internal and external domains. One way to set this up is split horizon DNS, but another way is to simply splice your internal zones into the configuration of your official caching nameservers by directly specifying master or forwarding servers for them.

(This is perfectly safe if your caching nameservers are already only accessible to internal machines.)

When you splice zones in this way, they do not necessarily have NS records (and even if they do, there are situations where clients may not be able to directly query the master nameservers for the zone). Instead, everything works because the official nameserver simply forwards queries and glues everything together for clients.

However, if you send a non-recursive query for one of those spliced zones to the upstream official nameserver, the upstream will not necessarily forward your query to the real DNS servers; after all, you told it not to do that. The result is that your query fails if the answer is not already cached in the upstream.

So if you are putting together a local caching nameserver, you really want it to be able to send recursive queries to the official machine. If it will only send non-recursive queries, you need to obtain, duplicate, and keep current all of the zone splices that the upstream nameserver does in order to get the same results. With recursive queries, you just need to recursively forward the top level splice point and you're done, which is a lot easier to set up and maintain.

(As it happens, we have just such a zone splicing official caching nameserver locally. When I was trying to do this with djbdns's dnscache it was a pain in the rear to set everything up, and I was one of the people maintaining the official caching nameserver.)

PS: hopefully this makes sense. I have not been able to actually try suitable dig queries to verify this behavior (although it would be unusual for BIND to invent phantom NS records at zone splice points), and I am slightly under the weather at the moment.