gdnsd is an authoritative-only DNS server written in C, intended for operators who need high-performance name service with geographic balancing and failover rather than caching or recursion.

What it is

gdnsd is a DNS server that answers authoritatively for zones you host and deliberately does nothing else: it offers no caching and no recursive resolution. The initial "g" stands for Geographic, because the server is built around a plugin system that can perform geographic (or other sorts of) balancing, redirection, and service-state-conscious failover, and the plugin system can also produce weighted address and cname records. It is written in C and uses pthreads with libev and liburcu to attain very high performance and low latency, and its codebase has a strong focus on being efficient, lean, and resilient.

In practice it solves the problem of serving large, latency-sensitive DNS workloads while steering each client toward a sensible backend — by geography, by weight, or by health. The geographically-aware features support the EDNS Client Subnet specification from RFC 7871, so the server can receive more-precise network location information from intermediate shared caches. It replaces the general-purpose authoritative+recursive servers common in Linux distributions when caching and recursion are not wanted, and it specifically replaces hand-rolled or static zone serving when traffic steering and health-aware failover are required.

Key capabilities

• Authoritative-only operation with no form of caching or recursive service.
• A plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover.
• Weighted address and cname records produced through the plugin system.
• EDNS Client Subnet support per RFC 7871 for more-precise network location data from intermediate shared caches.
• Very high performance, low latency service achieved in C using pthreads with libev and liburcu.
• A regression testsuite with full branch coverage on the core packet parsing and generation code, plus scripted QA tools for e.g. valgrind validation and clang-analyzer.
• Continuous integration through GitHub Actions workflows c-cpp.yml and codeql-analysis.yml.

Who uses it and how

• Operators who run an authoritative name server only and want to avoid running a recursive or caching resolver alongside it.
• Teams doing geographic load distribution across datacenters, using the balancing and redirection plugins to steer clients to nearer or healthier backends.
• Administrators performing service-state-conscious failover, where backend health checks influence which addresses or cname targets are returned.
• Sites serving traffic behind intermediate shared caches that pass EDNS Client Subnet data, allowing more accurate location-based decisions.
• Contributors and QA maintainers working from the source tree, where documentation ships in POD format and is installed as manpages and textfiles.

Getting started

Build from the source tree or a source tarball by following the INSTALL file, which lists prerequisites and the build procedure; releases are published at https://github.com/gdnsd/gdnsd/releases/.

How it compares

gdnsd stands alone in this registry.

When to use it — and when not

Do not pick it if you need DNSSEC, caching, or recursive resolution, because gdnsd explicitly supports none of these, and note that it is authoritative-only by design. The project also has a transition under way: development of the future 4.0 release, which ports the entire codebase from C to Zig, is moving to Codeberg at https://codeberg.org/gdnsd/gdnsd, while this GitHub repository remains the stable home of the 3.x releases — so operators should weigh which line they are committing to. Licensed under GPL-3.0, the software may also be a constraint for those redistributing it as part of proprietary products.