Blog Index

Sam Trenholme’s blog

MaraDNS release 3.5.0039

September 26, 2026

I have released MaraDNS 3.5.0039 today. It fixes two minor security bugs and has other updates.

Changelog

• Two AI-assisted minor security issues patched:

  1. It was possible to perform a denial of service to disable Deadwood’s DNS-over-TCP feature. (DNS-over-UDP was not affected)

  2. RFC8482 replies made public 19 bytes of memory in the heap. There does not appear to be any vulnerable private data leaked.

• askmara now has a raw mode, showing the raw DNS packet received, as well as support for AAAA queries. (one can now do askmara Lname.foo. to ask for name.foo’s ipv6 address)

• Improved formatting of HTML documentation: They now look nice on both modern desktop browsers and on mobile (i.e. phone) browsers.

• Deadwood’s default compile no longer generates any known Valgrind warnings.

• Deadwood’s entropy pool now uses a combination of /​dev/​urandom, the timestamp when Deadwood was started, Deadwood’s PID, and 112 calls to clock_gettime().

• lunacy (“maralunacy” if you will) updated to compile more cleanly and have working optional lfs and spawner support.

Security

Here in the age of AI, the number of security reports has really bloomed. Two minor security issues were found with the latest batch of AI security reports I have received.

One issue allowed someone to disable the DNS-over-TCP service with specially crafted packets. The DNS-over-UDP service was not affected, and this won’t affect most users since DNS-over-TCP is disabled by default.

The other issue is that ANY queries in Deadwood, when forming an RFC8482 reply, would transmit over the network 19 bytes of unallocated memory. There does not appear to be any sensitive data in those 19 bytes, and the bug has now been patched.

AskMara

askmara is a tool included with MaraDNS to perform DNS queries. It was originally written in 2001; with IPv6 having wide adoption, it has been updated to allow one to perform IPv6 queries more easily. In addition, askmara finally has a formal version number (1.0.0001) and its documentation has been updated.

Lunacy

The built in version of Lunacy (a Lua 5.1 fork with security hardening) has been slightly updated, to allow one to optionally have support for the lfs package (list files in a directory) and spawner (open up a sub-process with a two-way pipe) again. The build process has also been updated and is better documented.

MaraDNS’s version of Lunacy is very slightly different from the stand alone version of Lunacy, but both versions can run the same scripts (as long as the MaraDNS version of Lunacy has lfs and spawner enabled).

coLunacyDNS, which uses Lunacy, had its entire build process updated to make sure its embedded Lunacy correctly compiles without lfs nor spawner.

MaraDNS’s documentation

Lunacy is used to build all of the documentation from MaraDNS’s own Easy Journal format to various other formats (text files, man pages, markdown pages, and HTML pages).

The process for building HTML pages has been updated to have the pages look nicer both on modern desktop browsers, as well as on phone screen web browsers.

The entropy pool

Deadwood uses a cryptographically secure pseudo random number generator (CSPRNG) to combine multiple sources of entropy and then generate numbers which are very hard to guess; this is used to determine the query ID and query source port to make spoofing DNS replies more difficult.

Because of how the CSPRNG works, the randomness of numbers is at least as good as the best source of entropy it gets. For example, if the CSPRNG is seeded from four sources of entropy, and three of them don’t actually have good entropy, the CSPRNG is still making high quality random numbers if the final source gave it secure random numbers.¹

Back in 2007, I had Deadwood use the following sources of entropy:

• /​dev/​urandom (CryptGenRandom() in Windows)

• The timestamp when Deadwood was started

• Deadwood’s process ID

• A couple hundred bytes of uninitialized allocated memory

Using uninitialized allocated memory has always been described as leading to “undefined behavior”, but in 2007, the behavior was that we would get some kinda-random looking bytes which would give us a little more entropy.

Here in 2026, testing shows that the uninitialized memory is frequently replaced with 0s, giving us no entropy, and since using uninitialized memory does generate Valgrind warnings, I decided to find another source of entropy.

Deadwood now uses the following sources of entropy:

• /​dev/​urandom (CryptGenRandom() in Windows)

• The timestamp when Deadwood was started

• Deadwood’s process ID

• Deadwood now performs 112 calls to clock_gettime(), initializing a dummy copy of the CSPRNG between each call. Testing in Cygwin, Ubuntu 26.04, and Alpine Linux on x86_64 systems shows that each call to clock_gettime() generates at least one bit of entropy, giving us 112 or more bits of entropy independent of /​dev/​urandom. The Windows port, alas, can’t get good entropy this way (since its clock has less resolution than the POSIX standard clock_gettime()) but can get about 24 bits of entropy from its sub-microsecond timestamp.

The reason for this system is because, while /​dev/​urandom is secure on modern Linux kernels, Deadwood is designed to be compiled on a variety of POSIX compliant systems, and, in particular, embedded devices could very well have a /​dev/​urandom without good entropy. For example, there were issues with Linux’s /​dev/​urandom on Raspberry PI devices a while ago, resulting in people using a program called haveged to get better entropy. Indeed, Deadwood’s use of clock_gettime() is very similar to how haveged got entropy.

Compiling with newer compilers

Post-C23 compilers have broken a lot of programs, making programs that used to compile without issue no longer compile. That in mind, MaraDNS now has hardcoded in all of her makefiles the -std=c99 flag, to make sure MaraDNS always compiles to the 1999 version of the C standard.

The reason for using the 1999 standard is because, while I have updated MaraDNS to be able to compile with a C23 compiler, the majority of MaraDNS’s and Deadwood’s development was done while C99 was the current C language standard.

MaraDNS’s future

Now that I have cleaned up MaraDNS to be current here in 2026, the main updates will be security updates: While MaraDNS is remarkably secure (there has never been an attack stronger than remote denial of service found), AI assisted reviewers are able to find many more security bugs than they could in the pre-AI days, so there’s a pretty good chance I will need to make more security patches as other bugs are found by AI.

Footnote

1: There is theoretical attack where, if a given “entropy” source is actually malicious, and if said source has access to the numbers generated by other entropy sources, such source could, in theory, control the output of the CSPRNG. It would take 2**n work to control n bits of the output, and it requires being able to read the memory of the victim process. Once one has access to the memory of the victim process, one can perform easier and far more effective attacks, so this is not a real world concern.