+++ /dev/null
-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-<title>The case for PowerDNS</title>
-<author>PowerDNS BV (bert hubert <bert@trilab.com>) &nl;
-Trilab BV</author>
-<date>v1.0 $Date$</date>
-<abstract>
-This document describes what Global Server Load Balancing is, and how
-PowerDNS can be employed in a GSLB configuration
-</abstract>
-<toc>
-<sect>GSLB
-<p>
-GSLB, short for Global Server Load Balancing, is the act of distributing
-server traffic to different locations. Although not necessary, this is
-almost always done using a smart nameserver.
-<sect1>Typical GSLB implementation
-<p>
-A user enters the name of a site ('www.thesite.com') in his or her browser.
-This causes the operating system, often Windows, to send out a request to
-the ISP of the user, asking for the IP address of www.thesite.com. If the
-nameserver of the ISP doesn't know this address, it asks the nameserver of
-thesite.com.
-<p>
-This nameserver then contains the GSLB smartness. Based on the IP Address of
-the nameserver of the ISP, it determines which of the 'www.thesite.com'
-servers is closest.
-
-A multitude of algorithms is in use for determining which server is closest.
-Some of them employ the Border Gateway Protocol, BGP, which is used for
-global internet routing. Some use 'ICMP Ping' measurements, some use
-modified DNS Queries. The simplest algorithm is to use IP Netmasks, which
-are an easy rule of thumb for determining who assigned an IP Address, which
-also gives it probable location.
-
-<sect>IP Netmasks and Location
-<p>
-IP Addresses are asigned by only a few entities worldwide, the foremost
-being ARIN, RIPE and APNIC, who respectively manage North- and South
-America, Europe and surrounding areas, and the Asian Pacific Region.
-
-This allows for coarse grained identification of location. While not very
-precise, it is very robust and guaranteed to work. It can be likened to a
-very good rule-of-thumb. Other methods employ complicated and fragile
-techniques for determining the 'internet distance' to a site.
-
-For example, ICMP Ping measurements are becoming less and less valid. The
-advent of Distributed Denial of Service attacks has lead many internet
-providers to block or limit these packets. The aforementioned BGP router
-protocol gives distance in 'AS Hops' which are no longer a valid measure of
-distance, as many Autonomous Subsystems now spread the globe.
-
-<sect1>IP Netmasks Configuration
-<p>
-PowerDNS comes preconfigured with a reasonable set of IP Rules. These may
-need some maintenance over time. It is adviseable to get a Subscription with
-PowerDNS so as to receive updates.
-
-These rules come in several levels. The lowest level is based on who
-assigned the IP Addresses, ARIN, RIPE or APNIC. The second level contains
-exceptions to these major rules. Change is expected especially in this
-second level.
-
-<sect>GSLB Concepts
-<p>
-A number of concepts are used in the PowerDNS GSLB configuration:
-
-<descrip>
-<tag>Netblock</tag>
-A netblock is a range of IP Addresses. A number of Netblocks together are
-grouped in a Region.
-<tag>Region</tag>
-A Region might be called 'ARIN' or 'Surfnet', and consists of a limited
-number of Netmasks.
-<tag>Target</tag>
-A Target describes a set of servers in a single location. Target names might
-be 'UUnet Amsterdam', 'Level3 Amsterdam' or 'Genuity'.
-<tag>Route</tag>
-A Route assigns a certain Region to a Target. A sample Route might be:
-Assign all ARIN IP Addresses to Genuity.
-<tag>Schema</tag>
-A set of Routes, Regions, Netblocks and Targets is called a Schema. Many
-different domains may be assigned to this Schema, which then only needs to
-be defined once.
-</descrip>
-
-<sect>DNS Configuration
-<p>
-In order to Load Balance a domain it must be pointed at the GSLB Schema.
-This is typically done using a DNS CNAME on the nameserver of the domain
-that needs to be balanced.
-
-In order for this to work, the Schema name must resolve to the IP Address of
-PowerDNS.
-</article>
-
+++ /dev/null
-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-<title>The case for PowerDNS</title>
-<author>PowerDNS BV (bert hubert <bert@trilab.com>) &nl;
-Trilab BV</author>
-<date>v1.0 $Date$</date>
-<abstract>
-This document describes what PowerDNS is, how it works and how it can be
-maintained and operated.
-</abstract>
-<toc>
-<sect>The PowerDNS modular system
-<p>
-PowerDNS consists of four distinct modules:
-<itemize>
-<item>Internet Nameserver
-<item>Logical Engine
-<item>Query Backend
-<item>Web-enabled configuration
-</itemize>
-
-Each of these modules can function on its own, and is therefore eminently
-testable and provably correct.
-
-When a DNS query comes in ('What is the IP Address of come.to'), it is
-received by the Internet Nameserver, which parses the packet and sends it to
-the Logical Engine. The Logical Engine then tries to find the best answer
-possible to the question.
-
-To do so, it applies certain rules. Is 'come.to' a globally redirected host?
-If it isn't, is it perhaps an alias for another host? Or do we simply need
-to look up the IP address, and return that. Each of these questions is
-fielded to the Query Backend.
-
-This query backend often just translates the question into SQL, and passes
-it to a relational database, like Oracle, MS SQLServer or PostgreSQL.
-
-A web-frontend is provided for configuring PowerDNS. This frontend is
-multi-user aware, so responsibilities can be delegated, whereby each
-operator can only manage his or her domains.
-
-More on the frontend the relevant chapter.
-
-<sect>PowerDNS Operation & Operational Limits
-<p>
-PowerDNS has been designed to be easy to operate and to function robustly.
-For example, should an unexpected exception occur, the program is restarted
-automatically, within seconds.
-
-<sect1>Installation
-<p>
-PowerDNS can span multiple computers, which either all connect to the same
-database, or each have their own mirrored copy. Normally, PowerDNS is sold
-using an ASP model. However, our initial customer may choose to have a
-local, privately owned installation.
-
-We will assist or even perform the installation for such a customer.
-
-Engineered for simplicity, configuring the nameserver itself (not the
-domains, these are configured using the web-frontend) is done from one
-single point, with only a limited number of settings that need to be
-changed.
-
-<sect1>Operational Limits
-<p>
-Extensive benchmarking has convinced us that network capacity is more of a
-limiting factor than PowerDNS itself will ever be. In testing, the PowerDNS
-server sustained 1500 queries/s on a regular desktop PC for a prolonged
-period of time. It is assumed that this is more than even the biggest
-current nameservers need to handle.
-
-<sect1>Maintaining and configuring domains
-<p>
-Great care has been taken to make the maintenance and configuration of
-domains as easy as possible. Two modes are available, 'Wizard'
-and 'Advanced'. This latest mode is 'vocabulary compatible' with the Bind
-nameserver, so existing administrators will feel right at home. The Wizard
-mode has been stripped of all jargon, and should be easy to follow for most
-Internet users.
-
-The Wizard mode also performs stringent tests on the information entered by
-the operator, so as to prevent misconfiguration.
-
-<sect>Features
-<p>
-PowerDNS has the following features:
-<descrip>
-<tag>Regular nameserving</tag>
-A better performing and robust nameserver. Feature set is limited to current
-and near-future internet practices. Other nameservers often support arcane
-and outdated Name Classes, like those used at MIT in the 1980s. Supporting
-these classes involves shipping more code, which might contain more security
-problems and bugs. More on security in the relevant chapter.
-<tag>Failover</tag>
-When multiple webservers are available, PowerDNS can be configured to only
-return IP Addresses of the servers which are actually functioning. This
-feature has been available for a long time from companies like Alteon or
-Arrowpoint (now both Cisco property).
-
-However, these machines can only function on local networks, as they
-function as a network-element. All your servers need to be in the same
-location for this to work. This is clearly not appropriate in case of
-maximum availability.
-<tag>Global Redirection</tag>
-In combination with Failover support, it is possible to support smart global
-redirection, whereby American customers might get connected to a server in
-New York, whereas European customers might be served by a computer in
-Amsterdam.
-
-<tag>Mail forwarding</tag>
-Although not strictly a Nameserver function, PowerDNS supports very rapid
-and robust mail forwarding. This system has already been employed the past
-months to forward mail for the V3 domains. It is specially engineered to not
-fall over in case of database problems, should they occur, for example when
-the database is suffering from a Denial of Service, as recently happened.
-
-<tag>URL Aliasing</tag>
-Much of the same goes for this. Customers can use URL Aliasing to let them
-point their (sub)domain to other webpages.
-
-<tag>Mail hosting</tag>
-The entire concept of mail hosting was re-engineered because it was found
-that existing systems suffered from sub-optimal performance, with a large
-server able to handle only 50.000 mailboxes at a time.
-
-This support consists of SMTP, Pop and IMAP4, which makes it compatible with
-almost all webmail solutions available.
-
-</descrip>
-
-<sect>Security and Reliability
-<p>
-<sect1>Security
-<p>
-Nameserving is a complex business. Currently, it is evident that existing
-servers suffer from security and Denial of Service vulnerabilities.
-
-There are several reasons for these problems:
-<descrip>
-<tag>Support for obsolete protocols</tag>
-Nameservers currently in use support ancient pre-Internet protocols like
-Hesiod and Chaosnet. Even if you are an Internet-only user, like everybody
-these days, your nameserver will still respond to packets containing
-questions for these protocols. The code supporting these features stems from
-the early 1980s and hasn't been audited in ages.
-
-The support for these protocols also causes other nameservers to be bigger
-than they need be.
-
-<tag>Support for undesirable features</tag>
-This is the cause of the most recent bout of Bind problems. Bind
-supports 'inverse queries', also known as 'iqueries'. This is a Jeopardy like
-situation whereby you ask a nameserver 'Which question has this answer'.
-These questions are no longer appropriate in a time where the Internet can
-at best be considered a unfriendly place.
-
-<tag>Complete integration</tag>
-Current nameservers are completely integrated solutions, carrying within
-their codebase a complete database and replication facility - which is
-exposed to the world. By offloading this functionality to a separate
-Relational Database, complexity is vastly reduced. Furthermore, relational
-databases are very trusted systems - it is good to leave the hard work to
-them.
-
-<tag>Use of outdated languages</tag>
-With languages like C it is very easy to make programming mistakes which
-endanger system security. By using C++ with full typechecking and dynamic
-strings, a lot of problems are avoided. It is no longer possible
-to 'overflow the buffer', as it is called.
-</descrip>
-
-<sect1>Reliability
-<p>
-PowerDNS can be operated from two or more completely independent locations.
-Failure of the one does not hamper the other. Each of these locations can
-easily be redundant in itself. UDP, the protocol over which DNS questions
-are asked and answered on the internet, lends itself very well to clustering
-solutions. It is advised that each location consists of two unconnected
-computers in a failover setup. The 'Virtual Router Redundancy Protocol'
-suffices, one of the easiest ways to set up a redundant group of computers.
-
-Regular nameservers can only run off their secondary for a limited period of
-time (often measured in days!). PowerDNS does not have this limitation.
-
-<sect>Statistics, Logging & Monitoring
-<p>
-PowerDNS can be configured to keep extensive details on its operation. From
-these details, which are available in an easily parseable ASCII form, it is
-possible to compile statistics.
-
-Of possible interest are:
-<itemize>
-<item>Number of questions for which PowerDNS had no answer
-<item>Average time needed to find answer to a question
-<item>Number of questions per second handled
-</itemize>
-
-Should there be a need, graphs can be compiled in realtime using the popular
-MRTG utility, which is easily interfaced onto PowerDNS.
-
-<sect>PowerDNS as a Registrar or domain-merchant Backend
-<p>
-The Web-frontend that comes with PowerDNS is engineered to support millions
-of users simultaneously. When stripped of advanced features, it makes a fine
-platform for any Registrar or domain-merchant.
-
-Everything in PowerDNS has been designed for incredibly high performance, so
-it is possible to support huge numbers of users on limited amounts of
-hardware.
-
-There is no point in the system which needs to be implemented as a single
-computer - all parts can be grown to span multiple servers.
-
-<sect>Competition
-<p>
-Besides the widely used Bind nameserver, there are other solutions
-available. Each of these solutions has its pros and cons.
-<sect1>F5 3DNS
-<p>
-
-Based on an expanded version of BIND, it offers a lot of interesting
-features, like global redirection and loadbalancing. It needs
-several 'probes' at your datacenters, which attempt to measure network
-connectivity.
-
-Unclear how it scales to larger number of domains, or even subdomains. Might
-conflict with plans of being a 'subdomain registrar'.
-
-Can combine with the 'Big-IP Controller' for local failover and
-loadbalancing.
-<sect1>Cisco Distributed Director
-<p>
-Is a weird contraption, which has been reported to take up to an hour to
-process any configuration changes. Uses complicated BGP metrics to calculate
-the optimum server for a user. In our experience, BGP is no longer the right
-way to do so. BGP differentiates the internet into so called Autonomous
-Subsystems. These days however, most of the AS's out there spread the globe.
-
-The Cisco Distributed Director will not be able to differentiate via BGP
-between a server or user located in San Francisco or one in Moscow, if both
-are in the MCI Worldcom network.
-
-This machine also appears to require machines at each server location.
-
-Also unclear how it handles large numbers of domains, especially given the
-time it needs to process configuration changes.
-
-</article>
-
+++ /dev/null
-<!doctype linuxdoc system>
-<article>
-
-<!-- Title information -->
-
-<title>PowerDNS 1.2 Install & Usage guide
-<author>PowerDNS BV
-Trilab BV
-<date>v1.1 $Date$
-<abstract>
-This document provides information on how to install PowerDNS and on how
-to maintain it afterwards
-</abstract>
-
-<!-- Table of contents -->
-<toc>
-<!-- Begin the document -->
-<sect>Introduction
-<p>
-PowerDNS is a versatile high-performance modular nameserver that can answer
-questions based on a number of data sources, accessed via backend drivers.
-
-<sect>Compilation
-<p>
-See the INSTALL file that comes with the distribution.
-
-<sect>Syntax
-<p>
-The actual process is called 'ahudns' for historical reasons. It is expected
-that this will change in a future release.
-
-On startup, ahudns reads two files in the configuration directory
-(/usr/local/etc or /opt/ahudns/etc, or whatever was specified during
-compilation), ahudns.conf and ahudns.rc.
-
-<sect1>ahudns.conf
-<p>
-In the configuration directory, you will find ahudns.conf-dist which lists
-the small number of runtime configuration parameters available.
-
-These parameters can either be set via the commandline or via ahudns.conf.
-<descrip>
-<tag>cache-ttl=...</tag>
-Seconds to store packets in the PacketCache. Can be set to zero to
-disable the PacketCache entirely. This is non advised for busy sites. Values
-of in the order of 10 seconds already give appreciable hitrates (80%).
-<tag>default-soa-name=...</tag>
-Name to insert in the SOA record if none set in the backend. Either make
-sure that your backend data source contains complete SOA records, or set
-this to a useful value. This default to 'a.misconfigured.powerdns.server'!
-<tag>distributor-threads=...</tag>
-Default number of Distributor (backend) threads to start. This is very
-dependent on your needs and backend. Higher values are generally better, up
-to a point. MySQL performs very well with a value of 5, with tens of queries
-per second.
-<tag>fancy-records=...</tag>
-Process CURL, URL and MBOXFW records. These magic records are presently
-undocumented and should not be used.
-<tag>localaddress=...</tag>
- Local IP address to which we bind. It can be important to set this -
-PowerDNS can get confused by machines with multiple NICs.
-<tag>localport=...</tag>
- The port on which we listen. Should probably always be 53.
-<tag>loglevel=...</tag>
- Amount of logging. Higher is more. Do not set below 3
-<tag>out-of-zone-additional-processing | out-of-zone-additional-processing=yes | out-of-zone-additional-processing=no </tag>
- Do out of zone additional processing. Use this if all clients are
-trusted.
-<tag>smtpredirector=...</tag>
- Our smtpredir MX host. Used for the MBOXFW record.
-<tag>urlredirector=...</tag>
- Where we send hosts to that need to be url redirected. Used for URL
-and CURL.
-<tag>wildcards=...</tag>
- Honor wildcards in the database. Switch this off for a significant
-performance gain. Off by default.
-</descrip>
-
-<sect1>ahudns.rc
-<p>
-Given the fact that PowerDNS is very modular, it can't expect to have all
-backend modules available at compile time. Therefore modules are loaded
-dynamically at runtime. This is done by executing the ahudns.rc script found
-in the configuration directory, where ahudns.conf also resides.
-
-You will find ahudns.rc-dist which you can rename to ahudns.rc, and edit at
-will to have PowerDNS load additional modules.
-
-When no modules are loaded, the daemon responds to queries with a 'SERVFAIL'
-packet, indicating that client nameservers should query other servers.
-<sect>Controling ahudns
-<p>
-On startup, ahudns opens a 'controlsocket', which can be used to control the
-daemon. Use the provided 'dynloader' program to issue commands. The
-following commands can be useful:
-<descrip>
-<tag>list</tag>List all statistical variables available
-<tag>ping</tag>Ping the daemon - it will reply if all is well
-<tag>show</tag>Show the value of a specified variable
-<tag>quit</tag>Use this to shut ahudns down
-</descrip>
-
-Use like this: dynloader /opt/ahudns/var/ahudns.controlsocket [command]
-whereby the path refers to the controlsocket location. See the 'init.d'
-chapter for an easier way to control ahudns.
-
-<sect>Running ahudns
-<p>
-There are at least three ways of running ahudns & smtpredir.
-
-<sect1>Directly
-<p>
-By default ahudns runs in the foreground, and can be run from any directory.
-The configuration directory to use is compiled in. In case of problems (out
-of memory, fatal errors), it will exit and not restart by default.
-
-Stop the daemon with the 'killall' or 'pkill command'
-<sect2>With the safe_ahudns wrapper
-<p>
-A better way of running ahudns is with the safe_ahudns wrapper, which is
-distributed with PowerDNS.
-
-This approach is a lot like that taken by safe_mysql from the MySQL
-distribution, should ahudns ever fail for whatever reason, safe_ahudns will
-instantly restart it.
-
-To start ahudns, run '/opt/ahudns/bin/safe_ahudns &' and then check the log
-to see if the connection to the database succeeded.
-
-To stop, use the dynloader programm and pass the command 'quit', which will
-make the daemon exit with error code 99. safe_ahudns interprets 99 as a
-healthy exit with no need to restart the daemon.
-
-<sect1>Running controlled with init.d scripts
-<p>
-This is the preferred way of running ahudns. For easy control of both ahudns
-and smtpredir, use the init.d scripts provided in the 'sample' directory.
-They are usually placed in /etc/init.d, but because of unix variations, they
-are not installed there by default.
-
-Available commands are 'stop', 'start', 'status' and 'restart'. The init.d
-scripts use the safe_* wrappers internally, which will take care of
-restarting the daemons if needed.
-
-<sect>Virtual configurations: running multiple nameservers on a single server
-<p>
-In order to have any number of separate ahudns and smtpredir installations
-there is the ability to specify different configuration files and
-configuration names. This allows you to stop and start the right daemon with
-ease.
-
-By default, all configuration lives in /opt/ahudns/etc, but this can be
-changed with the '--config-dir' commandline option. The recommended layout
-for virtual configurations is:
-
-<tscreen><verb>
-/opt/ahudns/etc For default configuration
-/opt/ahudns/etc-customer1 Customer1 directory
-/opt/ahudns/etc-customer1/ahudns.conf Customer1 configuration
-/opt/ahudns/etc-customer1/ahudns.rc Customer1 backends
-/opt/ahudns/etc-customer2 Customer2 directory
-/opt/ahudns/etc-customer2/ahudns.conf Customer2 configuration
-/opt/ahudns/etc-customer2/ahudns.rc Customer2
-/opt/ahudns/var/ahudns.controlsocket Default control socket (for dynloader)
-/opt/ahudns/var/ahudns-customer1.controlsocket
-/opt/ahudns/var/ahudns-customer2.controlsocket
-</verb></tscreen>
-
-The init.d scripts are aware of virtual configurations. If the 'CONFIGNAME'
-parameter is set, they will automatically start and stop the right instance
-of the daemon, and also pass the name of the virtual configuration file.
-
-Be aware that your ahudns.rc script should refer to the right controlsocket!
-
-A typical virtual installation will have several ahudns- files in
-/etc/init.d, with each a differing CONFIGNAME in the first few lines.
-
-<sect>Logging
-<p>
-Logging is regular syslog, with facility DAEMON.
-
-</article>
-
\ No newline at end of file
+++ /dev/null
-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-<title>PowerDNS Overview</title>
-<author>PowerDNS BV (bert hubert <bert@trilab.com>) &nl;
-Trilab BV</author>
-<date>v1.0 $Date$</date>
-<abstract>
-This document describes what PowerDNS is and what it is for
-</abstract>
-<toc>
-<sect>What is PowerDNS
-<p>
-PowerDNS consists of:
-<itemize>
-<item>A Nameserver
-<item>A Mailserver
-<item>A Webserver
-</itemize>
-<sect1>What is a Nameserver?
-<p>
-A Nameserver is a device which translates a human-friendly name
-like 'www.cnn.com' into an Internet Protocol (IP) Address that can be used to
-connect to the actual webserver. This functionality is vital as the
-numerical IP Addresses are unknown to end users so an inability to serve
-names means an inability to serve webpages, or to receive mail.
-
-Due to the complexity and arcane rules surrounding the Domain Name System,
-only a very limited number of Nameserver implementations exist, with the
-vast majority of sites running the antiquated Bind program, which can trace
-it roots to the creation days of the Internet.
-
-<sect1>Nameservers are crucial and tricky to maintain
-<p>
-Nameservers are at the very core of the Internet. All domain operators will
-have experienced often day-long outages due to misconfiguration or other
-operator mistakes. This makes Nameservers somewhat of a no-go zone, with the
-actual configuration and server itself often considered sacred. Domain
-maintenance takes experience operators and is hard to delegate to junior
-personnel.
-
-<sect1>Fixing up the existing Nameservers is not enough
-<p>
-The current Bind program has a long history of security incidents, the most
-recent ones affecting nearly all Internet providers. Currently, even major
-providers are still running vulnerable versions of Bind. Neither HP nor Sun
-have released fixes recently, forcing companies running Nameservers to
-download unsupported versions directly from the Internet Software Consortium.
-
-Any enhancements which affect ease of use will not help improve the security
-situation. Bind predates the large-scale use of relational databases and
-therefore comes with its own built in directory. A paradigm of secure design
-is to use modular programs with clear trust relations between them.
-Integrating everything, including a complete database and replications
-mechanism within the Nameserver itself makes security nearly impossible to
-achieve.
-
-There is a clear need to reinvent the Nameserver.
-
-<sect>The PowerDNS Modular System
-<p>
-PowerDNS Nameserver consists of four distinct modules:
-<itemize>
-<item>Internet Nameserver
-<item>Logical Engine
-<item>Query Backend
-<item>Web-enabled configuration
-</itemize>
-
-Each of these modules can function on its own, and is therefore eminently
-testable and provably correct.
-
-When a DNS query comes in ('What is the IP Address of www.cnn.com'), it is
-received by the Internet Nameserver, which parses the packet and sends it to
-the Logical Engine. The Logical Engine then tries to find the best answer
-possible to the question.
-
-To do so, it applies certain rules. Is 'come.to' a globally redirected host?
-If it isn't, is it perhaps an alias for another host? Or do we simply need
-to look up the IP address, and return that. Each of these questions is
-fielded to the Query Backend.
-
-This query backend often just translates the question into SQL, and passes
-it to a relational database, like Oracle, MySQL, MS SQLServer or PostgreSQL.
-
-An error checking web-frontend is provided for configuring PowerDNS. This
-frontend is multi-user aware, so responsibilities can be delegated, whereby
-each operator can only manage his or her domains.
-
-<sect>Benefits
-<sect1>Modular security, use of a trusted database
-<p>
-Because of the fact that all data comes from a central database, the actual
-Nameserver is very small, outsourcing a lot of the complexity to existing
-and very well trusted database products.
-<sect1>Complete ISP integration into a single data warehouse
-<p>
-Use of a central data repository also means that, for the first time ever, a
-complete self contained ISP solution is possible. When a domain is added to
-the Webserver, the PowerDNS Nameserver is aware of this. If an email address
-is added to a domain, PowerDNS automatically sends the Internet to the right
-place to deliver the message.
-
-Although not obvious for the layman, this is a quantum leap improvement over
-the current situation where Nameservers are an unconnected and often
-independently or externally maintained part of a complete ISP solution.
-
-When operators first experience the integrated operation of PowerDNS they
-are often enveloped by a strong 'this is how it is supposed to be' feeling,
-only then realizing the strangeness of the situation up to now.
-
-<sect1>Very high performance
-<p>
-Storing and retrieving data at high speed is a problem that has been well
-solved by cheaply available database servers. By building on these existing
-products, PowerDNS scales just as well as the database. As there are
-database solutions out there that achieve tens of thousands of transactions
-per second, there is no bottleneck in sight.
-<sect1>Instant updates
-<p>
-Because of this high performance, it is possible to lower the so
-called 'Time To Live' of DNS answers. This in turn means that changes to the
-Nameservers configuration go live nearly instantaneously, instead of taking
-over 24 hours to propagate, as is usually the case.
-<sect1>Interoperability
-<p>
-PowerDNS is, by design, very open. By conforming to all Internet RFCs that
-apply, interoperation with everything currently in use is easily possible.
-The source is unencumbered and can easily be supplied to major customers,
-both for improvements or to diagnose operating problems.
-
-<sect>PowerDNS is a complete Nameserving ISP solution
-<p>
-For the first time, the creation of Internet services can be done from an
-integrated high-performance platform. By reinventing the Nameserver, all
-major ISP functionality can be offered from a single database of user and
-domain data.
-
-By allowing easy web-management of this solution, especially Nameserver
-configuration has become easier and more robust then ever, surpassing
-previous 'Bind front-end' solutions in both performance and reliability.
-
-</article>
-
+++ /dev/null
-<!doctype linuxdoc system>
-
-<article>
-
-<!-- Title information -->
-<title>PowerDNS technical overview</title>
-<author>PowerDNS BV (bert hubert <bert@trilab.com>) &nl;
-Trilab BV</author>
-<date>v1.1 $Date$</date>
-<abstract>
-This document contains a technical description of PowerDNS.
-</abstract>
-<toc>
-<sect>PowerDNS is a next generation authoritative nameserver
-<p>
-DNS is among the most mission-critical parts of the internet. While in
-essence very simple, current implementations are complicated applications
-with source code often spanning dozens of megabytes.
-
-The growth of the number of domains means that there is a growing need for a
-lean and mean nameserver that is capable of serving millions of users with
-millions of domains.
-
-The operation of PowerDNS consists of three different parts:
-<itemize>
-<item>Internet Interface
-<item>Logical Engine
-<item>Query Backend
-</itemize>
-
-The Internet Interface receives a question, and hands it to the Logical
-Engine. This Logical Engine then splits up the question into the
-sub-queries, which are handed to the Query Backend, which in turn sends
-queries to any number of data sources. The answer is then transferred back by
-the Logical Engine to the Internet Interface, which sends out the packet
-containing the requested data.
-
-<descrip>
-<tag>The Internet Interface</tag>
-PowerDNS supports receiving queries over UDP and TCP. When a question is
-received, relevant parts of the packet containing the question are compared
-to queries received earlier.
-
-<tag>The Logical Engine</tag>
-A DNS query cannot be translated directly into a backend query. A question
-might be 'What is the IP Address of www.site.com'. In order to answer this
-question, some separate steps need to be performed:
-
-<itemize>
-<item>Is this nameserver Authoritative for this domain, or any of its parent
-domains?
-<item>Do we have a Canonical Name for www.site.com?
-<item>Does www.site.com exist?
-<item>Do we have an IP address for it?
-<item>If we don't, do we know who does?
-<item>Possibly send IP addresses for the nameservers who do know
-</itemize>
-
-This algorithm is described at length in RFC 1034.
-
-<tag>The Query Backend</tag>
-A real life nameserver may have many data sources. Several customer
-databases might exist, as well as standard Zone files. The Query Backend
-fields questions to any number of backends, in a prescribed order. This
-allows for maximum flexibility.
-</descrip>
-
-<sect>Simplicity brings reliability
-<p>
-
-By building on top of existing databases, PowerDNS is as trustworthy as your
-favorite database. Data storage and retrieval is a well solved problem. A
-nameserver should not reinvent it. We support almost all industry standard
-databases and also do custom backend development to graft PowerDNS on an
-existing database or schema.
-
-Due to the completely from scratch implementation without an existing
-installed base to appease, PowerDNS has remained very lean and mean.
-
-Monitoring is at the root of reliability, so the PowerDNS runtime can be
-queried by external scripts. This enables the operator to be informed of any
-problems at an early stage. Some sample scripts for the popular MRTG program
-are supplied.
-
-<sect>Incredible performance
-<p>
-Because of the many steps of the algorithm prescribed by RFC 1034, just
-hooking on a database to a nameserver is not a recipe for great performance.
-Steps need to be taken to streamline the process.
-
-PowerDNS does so in two ways:
-<descrip>
-<tag>Reordering the steps of the algorithm</tag>
-It is often possible to skip some of the steps in the algorithm initially,
-and only perform the other steps when it is really needed, which is often
-not the case.
-<tag>The PacketCache</tag>
-The PacketCache is quite revolutionary in that it caches entire query
-packets for short amounts of time. This PacketCache is consulted before
-running the RFC 1034 Algorithm in the Logical Engine. In production, it has
-been confirmed that even a 1 minute cache can achieve a 80% hitrate and
-thereby prevent 4 out of 5 database queries from ever happening.
-</descrip>
-
-Benchmarking has shown that PowerDNS should be able to reach in the order of
-20.000 queries/second on a reasonably fast database. When using direct
-tables like those supported by Berkeley DB, 50.000 should be achievable.
-
-The use of POSIX Threads also allows PowerDNS to use a large number of
-processors efficiently on architectures that support it.
-<sect>Complete security
-<p>
-PowerDNS is written in highly portable C++ using the ISO Standard C++
-Library (STL). This Library comes with dynamic string classes which all but
-erase the possibility of the much feared buffer overflows that have been
-hitting other nameservers.
-
-The very modular design of PowerDNS also makes for strict internal
-interfaces which can prevent any undesired action from having deleterious
-effects.
-
-Due to the use of modern tools and libraries, PowerDNS consists of only 7000
-lines of source. This is very well auditable in a reasonable period of time
-and can be regarded as a trusted computing base.
-
-Because the database is most often external, it is highly useful to grant
-PowerDNS read-only access to that database. Even a successful compromise can
-than not easily be exploited, because the database refuses to accept updates
-from the nameserver.
-
-<sect>Special Functions
-<p>
-Besides doing lookups in well known databases such as Oracle, Microsoft SQL
-Server, MySQL, PostgreSQL and Sybase, there are special purpose backends
-available.
-
-<sect1>Very Large Zone support
-<p>
-For customers with very large zones and a lots of secondaries, a special
-module has been developed to meet the following goals:
-<itemize>
-<item>Absolute 100% robustness
-<item>Incremental updates
-<item>Near realtime updates
-<item>Idempotent update packets
-<item>Instantaneous zone reloading
-</itemize>
-
-In short, this means that updates are broadcast from a central point. These
-updates can be broadcast as many times as desired because there is no harm
-in applying them more than once. Each of these updates is applied within
-seconds.
-
-It does not use a relational database but instead relies on any of the
-well known table engines that are available, with a strong slant towards
-Berkeley DB.
-<sect1>Global Redirection
-<p>
-With the aid of a comprehensive map of IP addresses, it is possible to do
-smart routing of customers to servers geographically near them. While not
-providing pin-point accuracy, it is broadly effective and very fast.
-
-<sect1>DNS based loadbalancing and failover
-<p>
-Because of the efficiency of PowerDNS, it is feasible to use very low TTLs
-on answers. This in turn makes it possible to perform DNS based
-loadbalancing and failover. This can be very robust because the DNS
-infrastructure itself is redundant, whereas regular loadbalancing agents are
-themselves a single point of failure.
-
-<sect1>CORBA backend
-<p>
-By allowing questions to be asked over this industry standard protocol,
-it becomes trivially easy to integrate PowerDNS with existing middleware
-applications and/or customer databases.
-
-<sect>Standards compliance
-<p>
-PowerDNS is committed to being fully standards compliant. Current supported
-standards include RFC 1034, RFC 1035 and RFC 2181.
-
-<sect>Availability
-<p>
-PowerDNS is available immediately for use. It comes with completely
-documented source and a license that allows the end-user to improve and or
-change the source.
-
-Licensing is possible on a per-CPU or on a per-Domain basis.
-
-PowerDNS is a fully supported product with different levels of support
-available.
-</article>
-
projects / thirdparty / pdns.git / commitdiff
