You've come to this page because you've asked a question similar to the following:
People keep talking about "content DNS servers" and "proxy DNS servers". What are these ?
This is the Frequently Given Answer to that question.
The RFCs make the unfortunate unstated assumption that all DNS servers are fundamentally the same. This is an entirely unwarranted assumption. There are in fact several distinct rôles that a DNS server can perform.
DNS is in fact very much like HTTP. (This isn't surprising, if one thinks about it.) Like HTTP servers, DNS servers are categorized into two classes: content servers and proxy servers. Modern DNS softwares have separate programs that perform each rôle. (In comparison, old DNS softwares, such as BIND and Microsoft's DNS server, have one big program that vainly attempts to wear all of the hats at once.)
The RFC terminology is idiosyncratic and arcane, and suffers from widespread egregious mis-use, with people ending up using the terminology quite wrongly and then reasoning from that quite badly. Fortunately, the HTTP terminology is clearer, more widely understood, and indeed more usefully describes the architectures that systems in practice actually implement.
Content servers publish DNS content to the world. The data that they publish are taken from a database, or are generated internally by the servers themselves. (Content servers don't need caches, therefore.) If one owns one's own domain, one uses a content server to publish the DNS information about that domain.
Public content servers, which serve up the portion of the overall DNS database for one or more particular domains, receive incoming queries from the rest of Internet, so they have to listen on an IP address that can be reached by the rest of Internet.
Private content servers, in contrast, serve up an "internal" view of the DNS for a domain to a restricted set of clients (usually just one or more resolving proxy servers, because they are the second of the two content DNS servers in a "split-horizon" DNS service employing two content servers), and so do not need to listen on an IP address that can be reached by the rest of Internet.
Delegations in the DNS database always point to the IP addresses of content servers.
For the public DNS database, these must be public content servers, in order that everyone's resolving proxy servers are able to follow them and contact the content servers being delegated to. (Usually, resolving proxy servers are directed to private content servers by explicitly overriding the content of the DNS database, rather than by publishing delegations.)
How one tells the whole world where to look for one's content servers is not a matter that involves software. It involves human beings. If one owns the domain something.person., one contacts the people who own the person. servers, and pays them to have their content servers publish a referral pointing to one's own content servers. This referral will be the partial answer sent to anyone who asks them about something.person..
Commonly, the superdomain is a top-level domain, and the process of talking to the human beings who own its content servers is a formalized one involving middle-men.
DNS clients are never configured to talk directly to content servers. The IP address of a content server should not be listed in the /etc/resolv.conf file on Unix or Linux systems, for example.
DNS clients expect to receive complete answers, which content servers do not necessarily provide. Content servers may provide partial answers ending in referrals.
Content servers never talk to each other (unless they are using BIND's zone transfer mechanism for their database replication) or initiate communication with any other sorts of DNS servers.
Modern DNS packages have many programs that provide both general-purpose and specialised forms of content service.
In Daniel J. Bernstein's djbdns, tinydns, axfrdns, walldns, and rbldns are content servers.
In the Internet Utilities for OS/2, dnsbsd, dnsdsd, dnshsd, dnsosd, dnssd, dnstsd, and dnszsd are content servers.
Proxy servers act as intermediaries between DNS clients (such as an
application calling the gethostbyname() library function) and
other DNS servers. They handle outgoing queries. They answer those queries
from data that are obtained by sending one or more queries to other DNS
servers. Usually they cache those data, reducing traffic and latency in the
case that the data are frequently requested.
Proxy servers are further categorised into two subcategories: resolving proxy servers and forwarding proxy servers.
Resolving proxy servers talk directly to content servers. They perform the grunt work of query resolution.
Resolving proxy servers need to be able to talk to arbitrary content servers on the rest of Internet, as they follow the chain of referrals from content server to content server, working down from the root content servers, and thus must run on machines with direct connections to Internet.
Forwarding proxy servers talk only to other proxy servers, not directly to content servers. They don't perform resolution. They pass that work on to other proxy servers. They concentrate multiple streams of DNS traffic into a single stream.
Essentially there is a chain of (zero or more) forwarding proxy servers between the DNS clients and the resolving proxy server.
Forwarding proxy servers only need to be able to talk to the proxy servers that they have been configured to forward queries to. They do not need to be able to access the whole of Internet.
The choices of whether and where to deploy forwarding and resolving proxy DNS servers involve various decision criteria:
the proximity of one's own proxy DNS server to the rest of Internet
Often DNS lookups result in cache misses. (Non-cacheable content is - alas! - more popular than it ideally should be.) If one's own proxy DNS server is as near to the rest of Internet as the forwardee that one would forward queries to, a cache miss can actually be slower if one chooses to have a forwarding proxy DNS server forwarding queries rather than to have a resolving proxy DNS server performing query resolution itself. This is because the act of forwarding itself introduces an extra hop.
the cost, size, and usage of the link to the forwardee
If there is an expensive, slow, or congested link between the DNS clients and the resolving proxy server, it can be useful to interpose a caching forwarding proxy DNS server at the same end of the link as the DNS clients, acting as a traffic concentrator and eliminating redundant traffic over the link.
In the extreme case, there is a chain of forwarding proxy DNS servers, at the "local" end of each link, each forwarding to the next, with a resolving proxy DNS server at the border with the rest of Internet.
In less extreme cases, it is a good idea at least for every machine to have its own forwarding proxy DNS server running locally, if only to prevent duplicate traffic caused by repetitive processes and traffic for "host-local" lookups such as localhost. and *.127.in-addr.arpa. from even leaving the machine itself. (Some operating systems have caching DNS clients. These are usually inferior to real forwarding proxy DNS servers, inasmuch as they often operate at a higher level of abstraction which does not include the TTL information that the DNS proper has.)
the DNS namespace that the forwardee presents
The forwardee that would be used may present the wrong view of the DNS namespace (e.g. It is a resolving proxy DNS server that uses the wrong root; or it sees a different view of the namespace to the one desired because of "split horizon" DNS service.). In which case, one performs query resolution onesself, using a resolving proxy DNS server that presents the correct view.
the security and reliability of the forwardee
The forwardee that would be used may be vulnerable to poison insertion, or otherwise insecure, or simply unreliable. In such cases, one performs query resolution onesself, using a secure resolving proxy DNS server of one's own.
the loading on the forwardee
Ironically, the size of the organization providing the forwardee matters. Organizations with large numbers of customers/clients/users are likely to see a very low locality of reference in the queries sent to their proxy DNS servers, whereas organizations with small numbers of customers/clients/users are likely to see a higher locality of reference. A low locality of reference can cause thrashing, turning every transaction into a cache miss. As such, forwarding can be slower than performing query resolution directly.
the shape of hole that one is capable of knocking, or willing to knock, into one's firewall
Whether one uses a forwarding proxy DNS server or a resolving proxy DNS server affects the shape of the DNS-shaped hole that one has to knock into one's firewall.
Sometimes human ignorance dictates the shape of the hole.
For example: Daniel J. Bernstein, author of djbdns, reports that the network administrators at his organization prevented his resolving proxy DNS server working on 2003-10-11 because it was "scanning remote hosts on port 53".
the need for auditing, analysis, and problem diagnosis
Resolving proxy DNS servers are used in preference to forwarding proxy DNS servers in cases where the forwardee that would be forwarded to is not under one's own control and one wants to have direct access to query resolution log data for whatever reason.
ISPs often provide proxy DNS services to their customers. However, as with all such caching proxy services, the benefit is generally to the ISP, not to the customer. The main purpose of an ISP providing a caching proxy service, be it a caching proxy DNS service or a caching proxy HTTP service, is to reduce the traffic over its links with the rest of Internet (by collapsing identical transactions from multiple customers into one), and thus what it has to pay for. The main purpose is not access speed as far as the customer is concerned, contrary to common belief. (Indeed, as explained earlier, using one's own resolving proxy DNS server can in various situations actually be faster than having a forwarding proxy DNS server forwarding queries to the proxy DNS server provided by an ISP.) ISPs encourage their customers to use their caching proxy servers primarily for their own benefits.
Proxy servers handle all outgoing DNS queries originating from processes running on one's machines (or on the machines of one's paying customers). DNS clients are always configured to talk to proxy servers. The IP address of a proxy server will be what is used in the /etc/resolv.conf file on Unix or Linux systems, for example.
DNS clients expect complete answers, which only proxy servers provide.
Proxy servers do not need to be, and shouldn't be, accessible from the outside world. They must be configured to listen on IP addresses that are, quite simply, not reachable from the rest of Internet, and not reachable from outside of the machine, site, or organization whose clients they are providing service to.
Delegations in the DNS database never list the IP addresses of proxy servers.
Modern DNS packages have programs that provide proxy service.
In Daniel J. Bernstein's djbdns, dnscache is a (caching) proxy server, which acts as either a forwarding or a resolving proxy server according to the presence or absence of the FORWARDONLY environment variable.
In the Internet Utilities for OS/2, dnsfcpd is a forwarding caching proxy server and dnsrcpd is a resolving caching proxy server.