From: Pieter Lexis Date: Wed, 10 Dec 2014 18:25:02 +0000 (+0100) Subject: .sgml begone! X-Git-Tag: rec-3.7.0-rc1~82^2~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=360c5dd13ab7843e78bf6d94ee6bdfce7e305e16;p=thirdparty%2Fpdns.git .sgml begone! --- diff --git a/pdns/docs/gslb-operations.sgml b/pdns/docs/gslb-operations.sgml deleted file mode 100644 index 2b13cbe637..0000000000 --- a/pdns/docs/gslb-operations.sgml +++ /dev/null @@ -1,99 +0,0 @@ - - -
- - -The case for PowerDNS -PowerDNS BV (bert hubert <bert@trilab.com>) &nl; -Trilab BV -v1.0 $Date$ - -This document describes what Global Server Load Balancing is, and how -PowerDNS can be employed in a GSLB configuration - - -GSLB -

-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. -Typical GSLB implementation -

-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. -

-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. - -IP Netmasks and Location -

-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. - -IP Netmasks Configuration -

-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. - -GSLB Concepts -

-A number of concepts are used in the PowerDNS GSLB configuration: - - -Netblock -A netblock is a range of IP Addresses. A number of Netblocks together are -grouped in a Region. -Region -A Region might be called 'ARIN' or 'Surfnet', and consists of a limited -number of Netmasks. -Target -A Target describes a set of servers in a single location. Target names might -be 'UUnet Amsterdam', 'Level3 Amsterdam' or 'Genuity'. -Route -A Route assigns a certain Region to a Target. A sample Route might be: -Assign all ARIN IP Addresses to Genuity. -Schema -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. - - -DNS Configuration -

-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. -

- diff --git a/pdns/docs/powerdns-case.sgml b/pdns/docs/powerdns-case.sgml deleted file mode 100644 index 30d6c523d5..0000000000 --- a/pdns/docs/powerdns-case.sgml +++ /dev/null @@ -1,252 +0,0 @@ - - -
- - -The case for PowerDNS -PowerDNS BV (bert hubert <bert@trilab.com>) &nl; -Trilab BV -v1.0 $Date$ - -This document describes what PowerDNS is, how it works and how it can be -maintained and operated. - - -The PowerDNS modular system -

-PowerDNS consists of four distinct modules: - -Internet Nameserver -Logical Engine -Query Backend -Web-enabled configuration - - -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. - -PowerDNS Operation & Operational Limits -

-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. - -Installation -

-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. - -Operational Limits -

-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. - -Maintaining and configuring domains -

-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. - -Features -

-PowerDNS has the following features: - -Regular nameserving -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. -Failover -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. -Global Redirection -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. - -Mail forwarding -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. - -URL Aliasing -Much of the same goes for this. Customers can use URL Aliasing to let them -point their (sub)domain to other webpages. - -Mail hosting -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. - - - -Security and Reliability -

-Security -

-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: - -Support for obsolete protocols -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. - -Support for undesirable features -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. - -Complete integration -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. - -Use of outdated languages -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. - - -Reliability -

-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. - -Statistics, Logging & Monitoring -

-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: - -Number of questions for which PowerDNS had no answer -Average time needed to find answer to a question -Number of questions per second handled - - -Should there be a need, graphs can be compiled in realtime using the popular -MRTG utility, which is easily interfaced onto PowerDNS. - -PowerDNS as a Registrar or domain-merchant Backend -

-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. - -Competition -

-Besides the widely used Bind nameserver, there are other solutions -available. Each of these solutions has its pros and cons. -F5 3DNS -

- -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. -Cisco Distributed Director -

-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. - -

- diff --git a/pdns/docs/powerdns-install.sgml b/pdns/docs/powerdns-install.sgml deleted file mode 100644 index 5ba58cc1ec..0000000000 --- a/pdns/docs/powerdns-install.sgml +++ /dev/null @@ -1,183 +0,0 @@ - -
- - - -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 diff --git a/pdns/docs/powerdns-overview.sgml b/pdns/docs/powerdns-overview.sgml deleted file mode 100644 index 811521cb8f..0000000000 --- a/pdns/docs/powerdns-overview.sgml +++ /dev/null @@ -1,146 +0,0 @@ -<!doctype linuxdoc system> - -<article> - -<!-- Title information --> -<title>PowerDNS Overview -PowerDNS BV (bert hubert <bert@trilab.com>) &nl; -Trilab BV -v1.0 $Date$ - -This document describes what PowerDNS is and what it is for - - -What is PowerDNS -

-PowerDNS consists of: - -A Nameserver -A Mailserver -A Webserver - -What is a Nameserver? -

-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. - -Nameservers are crucial and tricky to maintain -

-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. - -Fixing up the existing Nameservers is not enough -

-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. - -The PowerDNS Modular System -

-PowerDNS Nameserver consists of four distinct modules: - -Internet Nameserver -Logical Engine -Query Backend -Web-enabled configuration - - -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. - -Benefits -Modular security, use of a trusted database -

-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. -Complete ISP integration into a single data warehouse -

-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. - -Very high performance -

-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. -Instant updates -

-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. -Interoperability -

-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. - -PowerDNS is a complete Nameserving ISP solution -

-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. - -

- diff --git a/pdns/docs/powerdns-technical.sgml b/pdns/docs/powerdns-technical.sgml deleted file mode 100644 index 192b4a8560..0000000000 --- a/pdns/docs/powerdns-technical.sgml +++ /dev/null @@ -1,193 +0,0 @@ - - -
- - -PowerDNS technical overview -PowerDNS BV (bert hubert <bert@trilab.com>) &nl; -Trilab BV -v1.1 $Date$ - -This document contains a technical description of PowerDNS. - - -PowerDNS is a next generation authoritative nameserver -

-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: - -Internet Interface -Logical Engine -Query Backend - - -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. - - -The Internet Interface -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. - -The Logical Engine -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: - - -Is this nameserver Authoritative for this domain, or any of its parent -domains? -Do we have a Canonical Name for www.site.com? -Does www.site.com exist? -Do we have an IP address for it? -If we don't, do we know who does? -Possibly send IP addresses for the nameservers who do know - - -This algorithm is described at length in RFC 1034. - -The Query Backend -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. - - -Simplicity brings reliability -

- -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. - -Incredible performance -

-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: - -Reordering the steps of the algorithm -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. -The PacketCache -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. - - -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. -Complete security -

-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. - -Special Functions -

-Besides doing lookups in well known databases such as Oracle, Microsoft SQL -Server, MySQL, PostgreSQL and Sybase, there are special purpose backends -available. - -Very Large Zone support -

-For customers with very large zones and a lots of secondaries, a special -module has been developed to meet the following goals: - -Absolute 100% robustness -Incremental updates -Near realtime updates -Idempotent update packets -Instantaneous zone reloading - - -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. -Global Redirection -

-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. - -DNS based loadbalancing and failover -

-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. - -CORBA backend -

-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. - -Standards compliance -

-PowerDNS is committed to being fully standards compliant. Current supported -standards include RFC 1034, RFC 1035 and RFC 2181. - -Availability -

-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. -

-