Entry

What is a "content" vs a "proxy" DNS server?

What is the different paradigm that djbdns uses?

What is the different paradigm that djbdns uses?

Sep 10th, 2001 07:44
Brian Coogan,

djbdns makes a distinction between a content server and a proxy 
server.  Bind makes no such distinction, and operates as both a proxy 
server and a content server.
A content server is a server which serves actual content - acting as a 
source for DNS records.  Tinydns is the content server part of djbdns.  
The data is taken from files or a database - for instance, tinydns data 
and data.cdb files act as the content for djbdns and the Bind zone 
files act as the content for Bind.  Users never talk to content 
servers; it's the proxy servers that request information from content 
servers to satisfy user requests they are in the process of resolving.  
This parallels, in the HTTP world, a webserver (Apache/IIS), which 
provides the actual content pages when requested.
A proxy server serves up records it has fetched from content servers.  
It does not generate any original content.  Dnscache is the proxy 
server part of djbdns.  Users ask a proxy server for a DNS resolution;  
the proxy servers then go and talk to content servers to find the 
answers.  This parallels, in the HTTP world, a web proxy server (Squid 
etc), which simply passes page requests on.
This new way of looking at things can be confusing for people used to 
the Bind paradigm since Bind does not make the distinction between a 
DNS content server (eg: tinydns) and a DNS proxy server (eg: 
dnscache).  djbdns makes this distinction because it actually makes the 
server software (and administration of it) tremendously simpler!
Understanding this distinction is *essential* to being able to 
succesfully implement djbdns.  A successful djbdns implementation 
involves one or more content servers and one or more proxy servers 
interacting.   The proxy server, dnscache, fetches data from content 
servers (tinydns) in response to user requests.  Content servers listen 
on externally visible addresses for incoming information requests and 
return the information from their databases.  It is this modular 
approach that actually gives you a lot of flexibility in your network 
design and reduces administration costs.
The page given below answers this question more succinctly and fully 
than can be duplicated here - go there for a detailed, well written and 
rigorous answer thanks to Jonathan De Boyne Pollard:
http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-server-roles.html
Why is it important to separate the caching from the authoritative 
content server?
Firstly, for security reasons - allowing recursion on an authoritative 
server opens it up to poisoning attacks.  See the following URL:
  http://www.sans.org/infosecFAQ/firewall/DNS_Spoof.htm
(found with a simple Google search: BIND cache authoritative poison
recursion)
Cricket Liu's own DNS & BIND book recommends separation of 
authoritative serving and caching in DNS & BIND, Chapter 11, "Security".
Secondly, Joe User on the internet should never have an opportunity to 
use your authoritative server's resources to look up his recursive 
queries. (Nor should anyone else, really, even those inside your 
organization).  Allowing this makes denial of service attacks possible.
(let me know if this answer was helpful or not, it's surprisingly hard 
to be succinct and clear on this, and improvement may be needed)
Acknowledgement:  Greg White - info on cache/authoritative separation.