Bortzmeyer Stephane $Date: 2004-01-27 16:03:03 $ If you do not outsource the hosting of your name servers, you will need to choose the software to serve the DNS queries for your TLD. Today, there are three possible choices with free softwareI considered only free software and software which is:Actively maintained and updated, Committed to abide by the DNS standards. : BIND (Berkeley Internet Name Domain), by far the most common nameserver in use. We will only consider its version 9. nsd (Name Server Daemon), an authoritative-only nameserver. PowerDNS, a nameserver which separates the DNS protocol engine from the backend which knows the records. You can have several backends, some are shipped with PowerDNS (a DBMS backend, for instance, to retrieve your data directly from the database). Here are some information to guide your choice.

The strength of BIND is that everybody uses it. But it does not mean it is the best, simply that, for a very long time, it was the only one. BIND 9 is the Apache of nameservers: widely used (you find people competent in BIND everywhere), documented in many books and articles, feature-richBrand new developments in DNS are often implemented on BIND first. , very configurable. BIND 9 is quite slow for a large TLD, according to all benchmarks but, if you have a small or medium zone (say less than 100 000 domains), it does not really matter: not everybody is in charge of '.com'! BIND uses the zone file format described in and has a very rich configuration language. Here is an example: zone "fr" { type master; file "/etc/bind/db.fr"; }; zone "nl" { type slave; masters { 192.93.0.4; }; file "db.nl"; }; BIND 9 supports DNSsec, IPv6At least on Linux-based systems, the IPv6 support is very broken: no way to listen on a specific address, for instance. and IXFR. Because it has a lot of functionalitiesAnd you cannot disable all of the useless ones at compile-time. , BIND's security is difficult to assert. Also, because of all these functionalities, BIND may be difficult to configure. Last, but not least, the general health of the Internet requires more diversity in nameservers. This is why it is good that we now have reliable alternatives. BIND is maintained by the ISC (Internet Software Consortium), a not-for-profit organization. Its licence is BSD-like. Its development is active, but quite closed (you need to be a formal member to have a read-only access to the CVS repository, for instance.

nsd is an authoritative-only nameserver. This means it is suitable for a TLD but not as a caching recursive nameserver for your local network. If you want to provide both services (TLD-serving and caching recursive) on the same machine, you can use BINDWhich historically merges the two functions, which is not a good idea, in my opinion. for both or you can use nsd on one IP address and BIND on one another, just for the caching recursive service. Both programs allow you to specify an IP address to use. nsd is very simple to configure and extremely fast even for very large zones. Because its code is much simpler than BIND's one, it is probably safer. nsd uses the same format for the zone file than BIND. But its configuration file is quite different. Here is an example: ; We are primary on this one zone fr primary/fr notify 192.134.7.250 ; And secondary on that one zone nl secondary/nl masters 192.93.0.4 nsd does not support DNSsec yet. In theory, it supports IPv6, although I was not able to make it work on a Linux-based system. You can use nsd on a primary name server (it can notifies its slaves and transfer them the zone) or on a secondary name server. The secondary service is more tricky. Since nsd basically ignores the notifications it receives from the primary, you have to schedule a zone transfer at proper intervals (or to poll the primary). nsd is maintained by the RIPE-NCC and the NLnet foundation in the Netherlands. Its licence is BSD-like. Its development is very active.

PowerDNS is a very original program. It is conceptually separated in two: a frontend which knows the DNS protocol and receives and send queries, and a backend, which talks to the record store, the place where the DNS records are kept. Several backends are shipped with PowerDNS: BIND, to use BIND zone files. PostgreSQL, to use a PostgreSQL database as its store (there is a MySQL backend as well) "pipe", which is a generic backend to talk with any program you want to write ("pipe" works like Squid redirectors). . You can also write your own backend (C++ is mandatory, but the "pipe" backend is very convenient if you prefer Perl or Python), the process is well documented. I personally find that the database backend, besides being quite slow, is quite useless: even if you want to store your data in a database (a good idea), extracting it to a BIND zone file is a very simple process. Reading directly from the DBMS is not necessary. But the ability to write your own backend is very interesting, for instance for Content Delivery Networks () such as Akamai, who wish to reply with a different IP address, according to the BGP location of the client. By default, PowerDNS is authoritative-only but a recursive backend is currently being developed. Otherwise, you can use PowerDNS on one IP address and BIND on one another, just for the caching recursive service. Both programs allow you to specify an IP address to use. PowerDNS can use BIND zone files, with the BIND backend. Its configuration file is quite simple: # launch Which backends to launch and order to query them in launch=gpgsql # PostgreSQL gpgsql-user=pdns # The zones are in the datastore, not in the configuration file, # unlike BIND. PowerDNS supports IPv6 transport without problems. For a proper processing of AAAA (IPv6) records, you need to set do-ipv6-additional-processing=yes and this requires at least PowerDNS 2.9.7. PowerDNS is maintained by a private company of the same name, located in the Netherlands, home of nameservers :-). Its licence is GPL. Its development is very active, with rapid changes when bugs are found.

We compared the above three nameservers using a fast server (a PC with two 2Ghz processors, 1 Gbytes of RAM and a GigaEthernet card). It runs the Debian operating system, "unstable" branch, with the Linux kernel 2.4.20. There was no activity at all besides of the DNS server. For each test, we start the nameserver from scratch, then we let it stablize (BIND starts slowly when there is a huge zone to load). PowerDNS was tested with the PostgreSQL backend and the file backend (which allows it to use BIND zone files). Another machine (with a very low activity) on the same Ethernet switch was the client. It used the queryperf program (in BIND9 contrib/ directory). The -t 2 option was used (-t 20 for PowerDNS/PostgreSQL). Several tests were performed, but the variation are under 5% (except PowerDNS/PostgreSQL). The test files (files containing the requests that queryperf will submit) contained one million of queries (except for PowerDNS/PostgreSQL). One quarter of the queries were for unexisting domains. nsd and BIND9 were tested with copies of the '.fr' (150,000 domains) and '.nl' (870,000 domains) zones. PowerDNS was tested only with '.fr'. Only BIND replies more slowly when the zone file is larger. nsd and BIND were not tuned (I used the standard Debian packages and did not changed anything in the configuration file). I tried some changes on PowerDNS configuration, with few results. nsd is much faster. Three times as fast as BIND. PowerDNS is very slow. PowerDNS cannot handle the load. It sometimes lose 100 % of the queries. By default, queryperf sends 20 queries together. PowerDNS soon trashes. The results are too irregular to be published. Soon, the server becomes unsusable and no longer replies even to a single dig.

PowerDNS people, when reading this survey, added the following remarks. PowerDNS performance page can be very instructive. If you need the utmost of performance, you may want to consider to run in 'all-cached' mode and invalidate parts of the cache when you make changes, as described in the URL above. If there is one major thing to remember, it is to turn off most logging. log-dns-details=off. Logging is very expensive, far more so than doing DNS in the first place! Results can be better the second time. PowerDNS can be considered a 'lazy loader' of zones. The first time you run PowerDNS, the cache is cold and all queries need database access. Secondly, PowerDNS sometimes is very slow on SMP systems. This is a glibc issue. Symptoms are massive 'cs' counts in vmstat 1 output caused by spinlocks that 'overspin'. RedHat has a lot of threading work incorporated which means that it should benefit from multiple processors. Stock Debian will probably be hurt by multiple processors!

BIND 9 with '.fr' : DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000000 queries Queries completed: 1000000 queries Queries lost: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Tue Apr 8 15:17:24 2003 Finished at: Tue Apr 8 15:19:12 2003 Ran for: 107.463156 seconds Queries per second: 9305.514906 qps NSD with '.fr' : DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000000 queries Queries completed: 1000000 queries Queries lost: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Tue Apr 8 15:20:34 2003 Finished at: Tue Apr 8 15:21:10 2003 Ran for: 35.941544 seconds Queries per second: 27822.956076 qps An example with PowerDNS/PostgreSQL on '.fr' (but the results vary wildly). DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000 queries Queries completed: 940 queries Queries lost: 60 queries Percentage completed: 94.00% Percentage lost: 6.00% Started at: Tue Apr 8 15:34:43 2003 Finished at: Tue Apr 8 15:35:52 2003 Ran for: 68.184267 seconds Queries per second: 13.786172 qps PowerDNS/file on '.fr' : DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000 queries Queries completed: 1000 queries Queries lost: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Tue Apr 8 16:02:17 2003 Finished at: Tue Apr 8 16:02:22 2003 Ran for: 5.057339 seconds Queries per second: 197.732444 qps BIND 9 on '.nl' : DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000000 queries Queries completed: 1000000 queries Queries lost: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Tue Apr 8 16:04:28 2003 Finished at: Tue Apr 8 16:06:52 2003 Ran for: 143.917643 seconds Queries per second: 6948.418409 qps nsd on '.'nl' : DNS Query Performance Testing Tool Version: $Id: nameserver.db,v 1.9 2004-01-27 16:03:03 bortzmeyer Exp $ [Status] Processing input data [Status] Sending queries [Status] Testing complete Statistics: Parse input file: once Ended due to: reaching end of file Queries sent: 1000000 queries Queries completed: 1000000 queries Queries lost: 0 queries Percentage completed: 100.00% Percentage lost: 0.00% Started at: Tue Apr 8 16:13:21 2003 Finished at: Tue Apr 8 16:13:51 2003 Ran for: 30.160825 seconds Queries per second: 33155.591732 qps

There are two sort of lies, lies and benchmarks.

A very good study and comparison was made by Brad Knowles.