# gdnsd: an authoritative-only DNS server with geographic balancing > gdnsd is a C implementation of an authoritative-only DNS server, written around a plugin system that does geographic balancing, redirection and failover, and it is deliberately not a resolver. It offers no caching, no recursion and no DNSSEC, and the 4.x rewrite is a port to Zig that has moved to Codeberg. **gdnsd/gdnsd** — Authoritative DNS Server - Repository: https://github.com/gdnsd/gdnsd - Website: http://gdnsd.org/ - Stars: 560 · Forks: 69 - Language: C - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/gdnsd-gdnsd ## Authoritative only, and that is the whole design gdnsd is an authoritative-only DNS server, and the README is unusually direct about what that rules out. It does not offer any form of caching or recursive service, and it does not support DNSSEC. There is a strong focus on making the code efficient, lean, and resilient. That is a smaller product than BIND or Knot, and for most people looking at a DNS server today, that is a problem rather than a feature. A recursive resolver is what a household or a small office needs, and gdnsd is not that. What it is for is the other half of the DNS system, the part that holds the authoritative record for a domain and answers for it, and it is aimed at operators who already have that role and want a server that does nothing else. The performance claim has a mechanism behind it. gdnsd is written in C and uses pthreads with libev and liburcu to attain very high performance, low latency service. liburcu is the userspace RCU library, so the concurrency model is read-copy-update with readers that never block, and libev is the event loop. Together they are a way of serving a very large number of concurrent UDP queries with low per-query overhead, which is the profile you want for an authoritative server facing a lot of resolver traffic. The project is written in C and is licensed GPL-3.0, with the standard redistribution and warranty disclaimers in the README. The homepage is gdnsd.org and the repository's default branch is main, though the CI badges in the README point at the master branch of the GitHub workflows. ## The plugin system, and what the g stands for The initial g in gdnsd stands for Geographic, and the plugin system is the reason the project exists. The README describes it as a plugin system for geographic, or other sorts of, balancing, redirection, and service-state-conscious failover. The plugin system can also do things like weighted address and cname records. Those are the four record behaviours that a stock authoritative server usually does not give you. Balancing spreads a query across a set of addresses, which is how a service is kept inside one region. Redirection sends a client somewhere else entirely, which is how a service is moved between regions. Service-state-conscious failover means the decision to send a client to a server depends on whether that server is currently healthy, not just on the static record. Weighted records let a share of traffic go to a canary or a test server. The plugin model is the mechanism, and it is also the extension point. A plugin is loaded into the server and consulted when the queried name matches its configuration, so the behaviour is a property of the server's configuration rather than of the resolver asking. The geographic features also support the EDNS Client Subnet spec from RFC 7871, for receiving more precise network location information from intermediate shared caches. That is the detail that makes the geographic part work in practice. A recursive resolver in the path normally truncates the source address, so without ECS the server sees the resolver's address rather than the client's, and a geographic decision based on the client would be a decision about the wrong place. With ECS, the resolver forwards a prefix of the client's subnet, and the balancing decision can be made against something closer to the real client location. ## The test suite, and the QA tooling around it The README claims the code has a decent regression test suite with full branch coverage on the core packet parsing and generation code, and some scripted QA tools for things such as valgrind validation and clang-analyzer. That is a specific and checkable claim rather than a vague one, and the repository layout backs it up. There is a t/ directory for the tests and a qa/ directory for the scripted quality assurance, alongside src/ for the server source, include/ for the headers, libgdnsd/ and libgdmaps/ as the two libraries, acaux/ for autoconf auxiliary files, m4/ for the macro files, configure.ac and Makefile.am for the autotools build, docs/ for the documentation sources, init/ for the service start-up files, and .astylerc for the code formatting configuration. The mention of clang-analyzer in the QA tooling is the more interesting half, since a static analyser run over a DNS packet parser is a meaningful thing to have automated. Packet parsing is the part of a DNS server that has to deal with untrusted input from anyone on the internet, and the project is not shy about that being the focus of its testing. The documentation is in POD format inside the source tree and is installed as manpages and textfiles on installation. That is a distribution model worth noting: there is no separate documentation website to fall out of date, because the documentation ships with the binary and is versioned with it. The README also points at the wiki on GitHub for wikified docs, and at the issue tracker for bug reports. ## Building it, and what the INSTALL file is for The README does not give the build commands itself. It says to see the INSTALL file for details on prerequisites and build procedure, for working from the source tree or a source tarball, and that is the project's instruction for installation. What can be read from the repository is the shape of the build. It is an autotools project, with configure.ac, Makefile.am and an m4/ directory for the macros, an acaux/ directory of auxiliary files, and the two libraries built alongside the server binary in libgdnsd/ and libgdmaps/. A .gitmodules file is present at the top level, so some dependencies are pulled in as submodules rather than being found on the system, and the .github/ directory holds the CI workflows referenced by the two badges in the README. The two badges are the C/C++ CI workflow and CodeQL, both pointing at the master branch. CodeQL on a DNS server is a static analysis pass aimed at finding defects in the C code, and it is the sort of check that belongs on a project that parses hostile packets. The release downloads are hosted on the GitHub releases page, and the project site is gdnsd.org. The most recent releases listed are v3.8.3 from 2024-09-20, v3.8.2 from 2024-01-04, and v3.99.0-alpha2 from 2023-06-13, with a last push to the repository on 2026-05-26. ## The port to Zig, and the split across two forges The README carries a notice that changes how you should think about this repository, and it is easy to skim past. There is an evolved development branch geared towards producing an eventual future 4.0 release, and the changes are significant, not the least of which is that the entire project has been ported from C to Zig. Active development of that future will happen on Codeberg, at codeberg.org/gdnsd/gdnsd. The GitHub repository will remain for quite some time, primarily as the stable home base of the 3.x and older releases, and will be the source of any further 3.x releases. So the project now has two homes with different jobs. GitHub is where the stable line lives and where further 3.x releases will come from, and Codeberg is where the future lives. The 4.0 line is a full language rewrite, not a feature release, which is the usual reason such a rewrite takes years: the C implementation's threading model, with pthreads and liburcu, maps onto Zig's concurrency primitives in ways that change the shape of the code, and the plugin interface has to survive that. The version list shows the gap. The 3.x line reached 3.8.3 in September 2024, and the 3.99.0-alpha2 tag from June 2023 is the last alpha. There is no 4.0 release yet, so anyone reading this has to decide whether they want the stable line, which is what GitHub offers, or to track the Zig work on Codeberg. ## Where gdnsd is the wrong choice Three cases point elsewhere. The first is a household, a small office, or anything that needs a resolver. The README says plainly that gdnsd does not offer any form of caching or recursive service, so a client configured to use it as its resolver will get nothing back. Unbound, PowerDNS Recursor, Knot Resolver and the resolver built into most consumer routers all fill that role, and they are the right answer for a network that has to answer questions about the whole internet rather than about one zone. The second is a zone that needs DNSSEC. gdnsd does not support DNSSEC, so a domain with signed records cannot be served by it as it stands. That is a hard boundary, not a configuration gap, and for a registrar or an registry it is disqualifying. The third is a team that wants a single codebase and a single support channel. With the 4.x work on Codeberg and the 3.x line on GitHub, a deployment now has a choice to make about which line it tracks, and documentation and fixes for the two will not always appear in the same place. That split is manageable, but it is a fact of the project now rather than something to be discovered later. If the requirement is DNSSEC and standard zone management, Knot covers that and gdnsd does not. If the requirement is a CDN-style split of clients across regional backends with health-aware failover, and the zone is small enough to serve without DNSSEC, then gdnsd's plugin model is the feature that the general purpose servers do not offer. ## Conclusion gdnsd fits an operator who already has authoritative DNS and wants a server that does one thing with a small footprint, and who has a use for geographic or weighted records that a stock implementation will not give them. It does not fit an operator who wants a recursive resolver, because the README states there is no caching and no recursive service, and it does not fit a team that needs DNSSEC, which it does not support. Before you adopt the 3.x line, note that the last push to this repository was on 2026-05-26 and the newest release here is v3.8.3 from 2024-09-20, and that the 4.x development has moved to Codeberg, where the port from C to Zig is under way. ## FAQ ### What is gdnsd? It is an authoritative-only DNS server written in C, using pthreads with libev and liburcu for high performance and low latency. It does not offer any form of caching or recursive service and does not support DNSSEC, and it is licensed under the GPL-3.0. ### What does the plugin system in gdnsd do? It provides geographic or other sorts of balancing, redirection, and service-state-conscious failover, and it can also do weighted address and cname records. The geographic features support the EDNS Client Subnet spec from RFC 7871, so more precise network location information from intermediate shared caches can be used. ### How do I build gdnsd from source? The README directs you to the INSTALL file in the repository for prerequisites and the build procedure, whether you are working from the source tree or a source tarball. The project uses autotools, with configure.ac, Makefile.am and m4/ macro files, and the documentation is in POD format, installed as manpages and textfiles. ### Is gdnsd still being developed, and where? There are two homes. The GitHub repository remains the stable home base for the 3.x and older releases and will be the source of any further 3.x releases, with the last push on 2026-05-26. Active development of the future 4.0 release, which involves a port of the entire project from C to Zig, happens on Codeberg. ### Can gdnsd resolve DNS queries for clients? No. The README states that gdnsd does not offer any form of caching or recursive service, so it answers authoritatively for zones it holds and does not resolve names for clients. A recursive resolver is a separate piece of software in any deployment that uses gdnsd. ## Sources - [gdnsd/gdnsd on GitHub](https://github.com/gdnsd/gdnsd) - [License: GPL-3.0](https://github.com/gdnsd/gdnsd/blob/main/LICENSE) - [Project website](http://gdnsd.org/) - [README](https://github.com/gdnsd/gdnsd/blob/main/README.md) - [Releases](https://github.com/gdnsd/gdnsd/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gdnsd-gdnsd