GDNSDgdnsd is an authoritative-only DNS server written in C using libev and pthreads with a focus on high performance, low latency Authoritative DNS service. It does not offer any form of caching or recursive service, and does not support DNSSEC. The initial "g" stands for Geographic, as gdnsd offers a plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover.

Feature-list blurb as of 0.67b (beta release):

Extremely fast and efficient (see Performance and Efficiency below) Supports traditional UDP, EDNS0, and TCP queries over IPv4 and IPv6. Uses regular RFC1035-format zonefiles (BIND-like) Supported standard RR types: A, AAAA, NS, CNAME, PTR, SOA, MX, SRV, TXT, SPF Supports wildcard names. Validates many aspects of your zone data at startup. Detailed logging of network oddities (ill-formed queries, etc) can be toggled at runtime via signals, default is off to avoid spamming the logs. Tiny HTTP service built-in for providing server statistics in HTML and CSV formats. Dynamic plugin API for resolving A/AAAA queries via custom code (geographic balancing, failover, etc). Built-in HTTP service monitoring, to feed failover information to the plugins above. Built-in chroot/privdrop code, always required when invoked as root. GNU autotools are in use, separate build dirs and targets such as "installcheck" work. For now, only recent x86/x86_64 Linux is supported, more portability may come later. Builds correctly with either gcc4 or clang (LLVM). Decent test suite in place. The core dnspacket parsing/generation code has 100% effective coverage.

Detailed manpages and docs are included with the distribution.

Dependencies / System reqs for building from release tarballsA recent Linux 2.6.x-based distribution with a modern gcc (or clang) and glibc x86/x86_64 architectures only (others may work, but no guarantees) libvscf If you want to run the optional testsuite (make check), you will also need Perl and the Perl modules Net::DNS and LWP. SimplicityIf all you need to do is serve an authoritative domain or two, all you need is your zonefiles and a simple, short gdnsd configuration file that looks like this:

zones: { example.com: {}, example.org: {} }Name the zonefiles the same as their respective zone names, place them in the same directory as the above configuration file, and invoke "gdnsd -c /path/to/config.file start".

If you need to do trickier things, a world of non-default options are available. See the gdnsd.config manpage.

Performance and EfficiencyTraffic rates:

To put things in perspective, In terms of rough orders of magnitude, when researchers talk about the query rates seen by top-level global DNS infrastructure, they're usually talking about numbers in the 10K to 100K queries per second range (and even then, if I read correctly, they're speaking about aggregate rate across several distributed servers).

Over a local loopback interface, gdnsd handles queries at these sorts of rates over a single socket on a single-CPU 1.6Ghz Sempron processor from circa 2005. Especially when balancing over multiple sockets and NICs, you're really only bounded by hardware performance with gdnsd. A multi-socket/thread gdnsd has done 211K/sec using 4 cores on a Linux machine here (again, over the loopback). All of these test results were accomplished with a 0% error/loss rate. All queries were answered completely correctly.

And really the work on scaling gdnsd has only just begun, there are more improvements in the pipeline.

Memory efficiency and load times for large datasets:

I use a copy of the official .net TLD from early 2010 as a benchmark reference for testing memory allocation and load times. For perspective, this .net zonefile is approximately 1GB in uncompressed form on disk, containing about 30 million lines of text, and delegating somewhere in the vicinity of 12 million distinct domainnames.

On my x86_64 test machine, using BIND9 configured as an authoritative server for this .net zonefile, BIND takes a little over 4 minutes to read in the zone data and begin serving queries. The memory usage of the server when it's done loading the data is around 2.7GB.

gdnsd loads that zonefile in 1 minute flat, and the final memory usage is 1.7GB. These are not insignificant differences for operational and engineering purposes. Further significant improvements in the zonefile loading times are already being planned. We may be able to eek out a little more memory savings (without costing runtime performance), but probably not by much as we're already approaching the practical limits.

Much of the memory efficiency comes from very careful data structure design, and much of the zonefile loading speed comes from the fact that the parser is a Ragel state machine.

Also, if you can configure the machine with enough memory to hold double gdnsd's memory requirements for your zone data (which shouldn't be hard for anyone short of the .com admins), gdnsd can do virtually instantaneous restarts with new zone data. It accomplishes this by loading in all of the data in the new daemon instance before shutting down the old and taking over its sockets. Of course, it will abort the operation and not stop the old instance if it detects any zonefile syntax errors (or anything else that prevents successful start of the new instance).

These are all just data points about what gdnsd is capable of at the extremes. gdnsd is also perfectly suitable to small environments as well, and will perform very admirably and efficiently on smaller zonefiles and slower query rates.

PluginsA core feature (and the reason for starting this project, although it's more of a niche thing) is that gdnsd has an API for dso-based plugins for pluggable address resolution (conceptually similar to Apache modules) for A/AAAA records.

Many possibilities exist for various forms of plugin-based dynamic address resolution based on geography, network topography, time/date, administrative policies, etc. The plugin API is not well documented yet, but 4 trivial example plugins are included to look at, and there's one real-world plugin available now: gdnsd-plugin-georeg, which uses MaxMind's commercial Region-format database to do geographic balancing and failover of a given hostname to a set of geographically dispersed IP addresses.

The core daemon also includes a basic HTTP monitoring service with anti-flap that plugins can use to make failover decisions. Sufficient hooks exist to implement your own custom monitoring solution as well. The state of services monitored by this code is also reflected in gdnsd's own HTTP output.

The sourceThe newly-refactored source is available at: http://code.google.com/p/gdnsd/source/checkout

In addition to the normal user requirements for building from distribution tarballs above, you will also need Ragel version 6.6 to build from svn checkouts.

The previous stable seriesPortions of the current gdnsd code date back as far as 2007. That stable line of development has continued up through gdnsd 0.11, published in Feb of 2010. These older versions used a separate set of perl-based software for handling configuration files and loading zonefiles, which then encoded all of that into a binary config for the main daemon. They also had no plugin system, instead having the functionality of gdnsd-plugin-georeg hardcoded into the daemon. They also do not support IPv6 listening, AAAA records, or wildcards, and use a very non-standard zonefile format.

On the upside, 0.11 is very stable and has been in production at commercial sites for quite a while now. The source is maintained in branches/old of the gdnsd repository. I wouldn't recommend it for new deployments today, but I will continue to address any important bugs found in 0.11 until well after the new code has matured to an equal point of stability.

Copyright and LicensingSome files within this distribution are externally sourced open source software, and are covered by their own seperate copyright and license terms. Notably:

All files in the subdirectory gdnsd/libev come from Marc Alexander Lehmann's libev distribution, and are covered by his separate LICENSE file, which is also included in that directory. His license is GPL-compatible (specifically, it is an either/or of GPL and other terms). Several autoconf-related files (macros and helper scripts and so-on) contain their own embedded copyright and GPL-compatible licensing terms. All actual gdnsd source code is Copyright © 2008, 2009, 2010 Logitech (my employer) and licensed under the terms of the GPLv3, and includes statements to that effect within the source files.