1
<!doctype linuxdoc system>
5
<!-- Title information -->
6
<title>The case for PowerDNS</title>
7
<author>PowerDNS BV (bert hubert <bert@trilab.com>) &nl;
9
<date>v1.0 $Date: 2002-11-27 16:18:23 +0100 (Wed, 27 Nov 2002) $</date>
11
This document describes what PowerDNS is, how it works and how it can be
12
maintained and operated.
15
<sect>The PowerDNS modular system
17
PowerDNS consists of four distinct modules:
19
<item>Internet Nameserver
22
<item>Web-enabled configuration
25
Each of these modules can function on its own, and is therefore eminently
26
testable and provably correct.
28
When a DNS query comes in ('What is the IP Address of come.to'), it is
29
received by the Internet Nameserver, which parses the packet and sends it to
30
the Logical Engine. The Logical Engine then tries to find the best answer
31
possible to the question.
33
To do so, it applies certain rules. Is 'come.to' a globally redirected host?
34
If it isn't, is it perhaps an alias for another host? Or do we simply need
35
to look up the IP address, and return that. Each of these questions is
36
fielded to the Query Backend.
38
This query backend often just translates the question into SQL, and passes
39
it to a relational database, like Oracle, MS SQLServer or PostgreSQL.
41
A web-frontend is provided for configuring PowerDNS. This frontend is
42
multi-user aware, so responsibilities can be delegated, whereby each
43
operator can only manage his or her domains.
45
More on the frontend the relevant chapter.
47
<sect>PowerDNS Operation & Operational Limits
49
PowerDNS has been designed to be easy to operate and to function robustly.
50
For example, should an unexpected exception occur, the program is restarted
51
automatically, within seconds.
55
PowerDNS can span multiple computers, which either all connect to the same
56
database, or each have their own mirrored copy. Normally, PowerDNS is sold
57
using an ASP model. However, our initial customer may choose to have a
58
local, privately owned installation.
60
We will assist or even perform the installation for such a customer.
62
Engineered for simplicity, configuring the nameserver itself (not the
63
domains, these are configured using the web-frontend) is done from one
64
single point, with only a limited number of settings that need to be
67
<sect1>Operational Limits
69
Extensive benchmarking has convinced us that network capacity is more of a
70
limiting factor than PowerDNS itself will ever be. In testing, the PowerDNS
71
server sustained 1500 queries/s on a regular desktop PC for a prolonged
72
period of time. It is assumed that this is more than even the biggest
73
current nameservers need to handle.
75
<sect1>Maintaining and configuring domains
77
Great care has been taken to make the maintenance and configuration of
78
domains as easy as possible. Two modes are available, 'Wizard'
79
and 'Advanced'. This latest mode is 'vocabulary compatible' with the Bind
80
nameserver, so existing administrators will feel right at home. The Wizard
81
mode has been stripped of all jargon, and should be easy to follow for most
84
The Wizard mode also performs stringent tests on the information entered by
85
the operator, so as to prevent misconfiguration.
89
PowerDNS has the following features:
91
<tag>Regular nameserving</tag>
92
A better performing and robust nameserver. Feature set is limited to current
93
and near-future internet practices. Other nameservers often support arcane
94
and outdated Name Classes, like those used at MIT in the 1980s. Supporting
95
these classes involves shipping more code, which might contain more security
96
problems and bugs. More on security in the relevant chapter.
98
When multiple webservers are available, PowerDNS can be configured to only
99
return IP Addresses of the servers which are actually functioning. This
100
feature has been available for a long time from companies like Alteon or
101
Arrowpoint (now both Cisco property).
103
However, these machines can only function on local networks, as they
104
function as a network-element. All your servers need to be in the same
105
location for this to work. This is clearly not appropriate in case of
106
maximum availability.
107
<tag>Global Redirection</tag>
108
In combination with Failover support, it is possible to support smart global
109
redirection, whereby American customers might get connected to a server in
110
New York, whereas European customers might be served by a computer in
113
<tag>Mail forwarding</tag>
114
Although not strictly a Nameserver function, PowerDNS supports very rapid
115
and robust mail forwarding. This system has already been employed the past
116
months to forward mail for the V3 domains. It is specially engineered to not
117
fall over in case of database problems, should they occur, for example when
118
the database is suffering from a Denial of Service, as recently happened.
120
<tag>URL Aliasing</tag>
121
Much of the same goes for this. Customers can use URL Aliasing to let them
122
point their (sub)domain to other webpages.
124
<tag>Mail hosting</tag>
125
The entire concept of mail hosting was re-engineered because it was found
126
that existing systems suffered from sub-optimal performance, with a large
127
server able to handle only 50.000 mailboxes at a time.
129
This support consists of SMTP, Pop and IMAP4, which makes it compatible with
130
almost all webmail solutions available.
134
<sect>Security and Reliability
138
Nameserving is a complex business. Currently, it is evident that existing
139
servers suffer from security and Denial of Service vulnerabilities.
141
There are several reasons for these problems:
143
<tag>Support for obsolete protocols</tag>
144
Nameservers currently in use support ancient pre-Internet protocols like
145
Hesiod and Chaosnet. Even if you are an Internet-only user, like everybody
146
these days, your nameserver will still respond to packets containing
147
questions for these protocols. The code supporting these features stems from
148
the early 1980s and hasn't been audited in ages.
150
The support for these protocols also causes other nameservers to be bigger
153
<tag>Support for undesirable features</tag>
154
This is the cause of the most recent bout of Bind problems. Bind
155
supports 'inverse queries', also known as 'iqueries'. This is a Jeopardy like
156
situation whereby you ask a nameserver 'Which question has this answer'.
157
These questions are no longer appropriate in a time where the Internet can
158
at best be considered a unfriendly place.
160
<tag>Complete integration</tag>
161
Current nameservers are completely integrated solutions, carrying within
162
their codebase a complete database and replication facility - which is
163
exposed to the world. By offloading this functionality to a separate
164
Relational Database, complexity is vastly reduced. Furthermore, relational
165
databases are very trusted systems - it is good to leave the hard work to
168
<tag>Use of outdated languages</tag>
169
With languages like C it is very easy to make programming mistakes which
170
endanger system security. By using C++ with full typechecking and dynamic
171
strings, a lot of problems are avoided. It is no longer possible
172
to 'overflow the buffer', as it is called.
177
PowerDNS can be operated from two or more completely independent locations.
178
Failure of the one does not hamper the other. Each of these locations can
179
easily be redundant in itself. UDP, the protocol over which DNS questions
180
are asked and answered on the internet, lends itself very well to clustering
181
solutions. It is advised that each location consists of two unconnected
182
computers in a failover setup. The 'Virtual Router Redundancy Protocol'
183
suffices, one of the easiest ways to set up a redundant group of computers.
185
Regular nameservers can only run off their secondary for a limited period of
186
time (often measured in days!). PowerDNS does not have this limitation.
188
<sect>Statistics, Logging & Monitoring
190
PowerDNS can be configured to keep extensive details on its operation. From
191
these details, which are available in an easily parseable ASCII form, it is
192
possible to compile statistics.
194
Of possible interest are:
196
<item>Number of questions for which PowerDNS had no answer
197
<item>Average time needed to find answer to a question
198
<item>Number of questions per second handled
201
Should there be a need, graphs can be compiled in realtime using the popular
202
MRTG utility, which is easily interfaced onto PowerDNS.
204
<sect>PowerDNS as a Registrar or domain-merchant Backend
206
The Web-frontend that comes with PowerDNS is engineered to support millions
207
of users simultaneously. When stripped of advanced features, it makes a fine
208
platform for any Registrar or domain-merchant.
210
Everything in PowerDNS has been designed for incredibly high performance, so
211
it is possible to support huge numbers of users on limited amounts of
214
There is no point in the system which needs to be implemented as a single
215
computer - all parts can be grown to span multiple servers.
219
Besides the widely used Bind nameserver, there are other solutions
220
available. Each of these solutions has its pros and cons.
224
Based on an expanded version of BIND, it offers a lot of interesting
225
features, like global redirection and loadbalancing. It needs
226
several 'probes' at your datacenters, which attempt to measure network
229
Unclear how it scales to larger number of domains, or even subdomains. Might
230
conflict with plans of being a 'subdomain registrar'.
232
Can combine with the 'Big-IP Controller' for local failover and
234
<sect1>Cisco Distributed Director
236
Is a weird contraption, which has been reported to take up to an hour to
237
process any configuration changes. Uses complicated BGP metrics to calculate
238
the optimum server for a user. In our experience, BGP is no longer the right
239
way to do so. BGP differentiates the internet into so called Autonomous
240
Subsystems. These days however, most of the AS's out there spread the globe.
242
The Cisco Distributed Director will not be able to differentiate via BGP
243
between a server or user located in San Francisco or one in Moscow, if both
244
are in the MCI Worldcom network.
246
This machine also appears to require machines at each server location.
248
Also unclear how it handles large numbers of domains, especially given the
249
time it needs to process configuration changes.
added
removed
pdns/docs/powerdns-case.sgml
