# MaraDNS: a small DNS server parked in deep freeze

> MaraDNS is a compact C DNS server written by Sam Trenholme whose source tree bundles three separate servers, a recursive resolver and a Lua scripting engine. It is easy to build and easy to configure, but it has been in deep freeze since late 2022, so adopting it means tracking a repository that only changes to patch security holes and compile errors.

**samboy/MaraDNS** — MaraDNS: A small open-source DNS server

- Repository: https://github.com/samboy/MaraDNS
- Website: https://samboy.github.io/MaraDNS/webpage
- Stars: 573 · Forks: 69
- Language: C
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/samboy-maradns

## Deep freeze since late 2022, with patches only for holes and compilers

The README is unusually candid about the state of the project. MaraDNS has been, since late 2022, in deep freeze, and updates arrive only to fix important security holes or compile errors in either GCC or clang. The last hole found was in 2026, and the README states that no attack stronger than remote denial of service has ever been found in the server. The repository was last pushed on 2026-10-15, and it publishes no GitHub releases at all, so there is no versioned artefact to pin and no changelog entries to match a tag. CHANGELOG.TXT exists at the top level, but a file name is not a release history you can rely on for a deployment.

Two forward-compatibility efforts stand out. The code was updated to be Y2038 compliant, and MaraDNS is compiled with the std=c99 flag so that future changes in C compilers are less likely to break the build. The author also notes that external dependencies have multiple implementations: the scripts that convert MaraDNS documentation were moved from Perl to Lua, partly because several Lua implementations exist, including one shipped in the MaraDNS source tree. The README claims the code generates no warnings with -Wall in GCC 16 and Clang 20. That is a portability stance, not a development pace, and it matters when you are deciding who will fix the next problem you hit.

## One tree, three servers: maradns, Deadwood and coLunacyDNS

The repository is not a single daemon. The README names three pieces: MaraDNS itself as the authoritative server, Deadwood as the recursive server, and coLunacyDNS as a simple DNS server with Lua 5.1 scripting support. The top level directory listing matches that split, with directories for the server, the deadwood-github tree, the coLunacyDNS tree, and support code for parsing, quality checks, random number generation, TCP, UTF-8 handling and tests. The window server directory holds a full software stack, so the release contents are self-contained rather than a thin wrapper around system libraries.

The three components differ in a way that matters operationally. The authoritative server answers from configuration you write. Deadwood performs recursion. coLunacyDNS answers with replies that Lua code customises, and the README names the coLunacyDNS service as the most notable feature added during the COVID-19 pandemic, when new features were still being added. Windows support is uneven: the authoritative server needs third party utilities to run as a service on Windows, while Deadwood and coLunacyDNS have built-in Windows service support. Prebuilt 32-bit Windows binaries live in the maradns-win32 folder.

The same code is mirrored on GitLab, Bitbucket, Codeberg, SourceForge and SourceHut, and the README asks people to use GitHub discussions for bug reports. Localised resource files exist for German, English, Spanish, Brazilian Portuguese and Russian.

## Building from source with configure, clang and a separate coLunacyDNS makefile

There is no package install path described in the README, so the documented route is a source build from the top level directory. The build needs a POSIX compatible shell, a POSIX compatible make that permits a slash in a target, the usual POSIX utilities such as awk, and a C compiler that supports the -std=c99 flag and 8-bit through 64-bit sized integers through stdint. The C library must offer POSIX 2001 plus Berkeley sockets, and it must provide mkstemp and strnlen, neither of which POSIX covered securely or at all until 2008. Typical distribution package names for the toolchain are clang, libc-dev and make.

This is the build sequence the README gives for a normal POSIX system:

```
./configure
CC=clang
export CC
make
cd coLunacyDNS
make -f Makefile.default
```

The last two lines matter. coLunacyDNS does not build with the top level Makefile; it has its own default makefile, which is why the build switches directory and names the file. If you stop after the first make, you end up with the authoritative server and Deadwood but no Lua capable server. The author recommends clang over GCC because GCC is described as a moving target, and as of 2026-07-04 the project was reported to compile without errors or warnings under GCC 15, GCC 16, Clang 20, Clang 21 and TCC 0.9.27. Builds have been exercised on Ubuntu 26 with glibc, Cygwin, and Alpine Linux 14 and 24 with musl libc. A pure POSIX make implementation is available as maramake, but the make command itself must be named make.

## The strict-posix build path exists because chroot and setgroups are not POSIX

MaraDNS leans on two system calls that are widely deployed but never part of POSIX: chroot for confinement and setgroups for privilege management. A platform that lacks them is not an exotic edge case for a DNS server that aims to run on small and unusual hosts, so the configure script has a dedicated mode for it:

```
./configure --strict-posix
CC=cc
export CC
make
cd coLunacyDNS
make clean
make -f Makefile.strict
```

The differences from the normal build are the configure flag, the choice of the system cc as compiler, and the coLunacyDNS makefile used, which is Makefile.strict rather than Makefile.default. The extra make clean step exists because a strict build should not inherit object files from a previous non-strict build. If your libc does not implement chroot or setgroups, this is the path, and the trade-off is that the confinement features those calls provide are not available to you.

The Windows port is a separate story. It is compiled with a version of MinGW and MSYS from the first 2000s decade, and the README says it compiles fine under Cygwin and should compile with a newer MinGW compiler, though that is untested. A 32-bit Windows binary folder and a Makefile.windows-g file are present in the tree. Documentation building additionally uses unix2dos, a non-standard but widely available text conversion utility.

## Where MaraDNS is the wrong tool, including a startup that needs /dev/urandom

The clearest disqualifier is at startup. The README states that on a system without /dev/urandom, MaraDNS will not start. /dev/urandom is not part of POSIX, so this is a hard dependency on the host rather than a soft preference, and the Windows port avoids it by using Windows specific calls to get entropy. In a container or embedded image that omits the device, the server will not come up, and there is no documented fallback.

The second issue is timeline. A project in deep freeze is a reasonable way to avoid churn, and the security track record described in the README is good, but it means the security response depends on one maintainer. Combined with the absence of GitHub releases, an operator cannot point at a supported version, and every patch arrives as a commit on a default branch named master.

Configuration style is the third. The README describes the server as easy to configure for someone comfortable editing text configuration files, and that is a real advantage for a small host with a handful of zones. It is a liability for an environment where changes must be pushed through an orchestrator or a config management tool. A Docker-stuff directory exists in the tree, but the README does not document how to build or run a container image, so that path is not supported guidance. For a high query volume or a requirement for a maintained upstream with its own release train, MaraDNS is the wrong tool and the honest answer is to look elsewhere.

## Picking between the plain server and the Lua scripted server

The closest thing to a design alternative inside this project is the choice between the plain authoritative server and coLunacyDNS. They answer questions by different mechanisms. The authoritative server works from configuration you write in a text file, which suits static zone data and a setup that changes rarely. coLunacyDNS is a separate small server with Lua 5.1 scripting support whose replies are customised by Lua code at request time, and it is the component to reach for when an answer depends on a query rather than on a file. The README reports that the coLunacyDNS service was the most notable of the features added during the pandemic period, when feature work was still happening.

The recursive path is different again, and it is a separate program. Deadwood performs recursion and exists so that the server can answer for names it does not hold. Running it means running and reasoning about a recursive resolver, with its own configuration, and the README lists it as a distinct component rather than a mode of the main server. The three components share a tree, a licence and a maintainer, but they are not interchangeable.

Deployment shape follows from that. coLunacyDNS and Deadwood have built-in Windows service support, while the authoritative server needs outside utilities to become a service on Windows, so on a Windows host the choice of component is partly dictated by the service wrapper you already have. On Unix, the makefile split is the practical detail: coLunacyDNS is built with its own makefile, and skipping it leaves you without the Lua engine.

## The LICENSE file and the README disagree about what the licence is

The README states that MaraDNS is released under a BSD license. The repository's license field is marked as a custom licence that GitHub cannot classify, with a pointer to the LICENSE file. Those two statements sit in mild tension, and the tree reinforces that licence is a live concern here: a COPYING file sits at the top level, and a signing key, its how-to document and an older copy of the key are all committed.

For an engineer, the practical point is narrower than a legal opinion. BSD style terms are permissive and are widely compatible with commercial redistribution and with linking into larger stacks, but a custom licence may add or remove conditions the BSD label implies, and the authoritative text is the LICENSE file in the tree. Anyone planning to vendor MaraDNS into a product, redistribute it in an appliance image, or ship it to a customer should read that file rather than rely on the word BSD in the README. Contributors are pointed at a separate code of conduct document and a contributing document, which suggests the project keeps its own contribution and conduct expectations separate from the licence itself.

## Conclusion

MaraDNS is a reasonable fit for someone who wants a text-file configured authoritative server, a recursive resolver in Deadwood, or Lua-driven answers from coLunacyDNS on a small host, and who is comfortable compiling from a git tree rather than installing a packaged release. It is the wrong choice for an operator who needs vendor support, a predictable release cadence, or a resolver that upstream will keep patching. Before committing, check the LICENSE file against the BSD statement in the README, confirm your system exposes /dev/urandom, and build with clang and the --strict-posix configure path if your C library lacks chroot or setgroups.

## FAQ

### What is MaraDNS and who is it for?

MaraDNS is a small, lightweight, cross-platform open-source DNS server written in C by Sam Trenholme, and it is mostly POSIX 2001 and C99 compliant. It is aimed at people who want a text-configured authoritative server, the Deadwood recursive resolver, or the Lua scripted coLunacyDNS server on a modest host.

### How do I build MaraDNS from source?

From the top level directory, run ./configure, set CC to clang and export it, then run make, then cd coLunacyDNS and run make -f Makefile.default. The build needs a POSIX shell, awk, a make named make, a C99 compiler and a C library with sockets, and the server will not start on a host without /dev/urandom.

### Is MaraDNS still actively developed?

No. The README says it has been in deep freeze since late 2022 and is updated only to fix important security holes or compile errors in GCC or clang, and the last push to the repository was on 2026-10-15. The project publishes no GitHub releases, so there is no tagged version to track.

## Sources

- [Issues](https://github.com/samboy/MaraDNS/issues)
- [Project website](https://samboy.github.io/MaraDNS/webpage)
- [README](https://github.com/samboy/MaraDNS/blob/master/README.md)
- [samboy/MaraDNS on GitHub](https://github.com/samboy/MaraDNS)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/samboy-maradns