This separation is widely recognized as the right way to run DNS. As stated in the ``DNS and BIND'' book, third edition, ``Securing Your Name Server,'' page 255:
Some of your name servers answer nonrecursive queries from other name servers on the Internet, because your name servers appear in NS records delegating your zones to them. ... You should make sure that these servers don't receive any recursive queries (that is, you don't have any resolvers configured to use these servers, and no name servers use them as forwarders).BIND promoter Brad Knowles, who is usually willing to say anything to try to scare people away from djbdns, admitted in slide 45 of a 2002.11 presentation that servers should be separated from caches:
Split functions onto separate machines or IP addresses. Authoritative servers should be authoritative-only. ... Recursive/caching servers should not be authoritative.The BIND company (which has always separated its own f.root-servers.net server from its caches) issued a statement in 2002.12 saying the same thing:
Although BIND can provide both functions (authoritative and non-authoritative) in single instance, ISC recommends always separating these two functions. In other words, you should run one server for your authoritative zones, and another that caches non-authoritative data.If you've made the mistake of setting up a BIND site with a cache and a server on the same IP address, fix it! Step-by-step instructions for this fix are included in the djbdns upgrade instructions. You should correct the mistake even if you aren't upgrading.
Unfortunately, the idea of combining a cache with a server hasn't been stamped out yet. Brad Knowles, in slide 74 of the same presentation, listed as a ``djbdns Con'' the fact that dnscache and tinydns are separate programs that cannot run on the same IP address. The BIND company's software-installation instructions continue to fool unsuspecting users into putting a cache and a server on the same IP address.
The rest of this page explains several reasons that it's important to separate caches from servers.
As another example, suppose that a local user floods your DNS cache with more work than it can handle. If that same program is also running your DNS server, the flood will disrupt not only your site's outgoing web connections, but also your site's incoming web connections.
By separating DNS caches from DNS servers, you protect your DNS servers from DNS cache problems, and vice versa.
This is why RFC 2010 and RFC 2870 tell root server operators to use separate caches, and why the ``DNS and BIND'' book tells all server operators to use separate caches. In the words of the book, this separation ``eliminates a major vector of attack.''
Similarly, most DNS server programs do only one thing: publish DNS data. They aren't caches. By separating DNS caches from DNS servers, you allow yourself to easily replace your DNS server software without any effect on your DNS caches. (Analogy: you can upgrade from Apache to another HTTP server without any effect on Squid.)
In short, the separation gives you extra flexibility in choosing software. You aren't tied to monolithic server+cache programs. Look at the picture in RFC 1035, page 6: you can choose different software for the ``user program'' (client), the ``resolver'' (cache), and the ``name server'' (server).
This extra flexibility allows easier competition among DNS implementations. It makes new DNS servers much easier to write, because server implementors don't have to worry about all the complications of caching. Similarly, it makes new DNS caches easier to write.
This competition means that the software evolves more quickly. It keeps implementors on their toes. In the long term, everybody benefits from modularity, flexibility, competition, and evolution; you should support modularity even if you're satisfied with a monolithic server+cache program right now.