I have released MaraDNS 3.5.0011. The biggest change is that the testing is more automated: I now have a cron tab which runs a Podman (Docker-compatible) container every night and performs a number of automated tests against MaraDNS and Deadwood.
Since this test battery takes nearly an hour to run, the tests would only be run when making a new MaraDNS release. By running them every night, this will make regressions easier to track down.
While it’s still quite unstable, I am in the process of making a Lua-based DNS server called coLunacyDNS. This code is an update to mmLunacyDNS; it adds IPv6 record support (IPv6 sockets aren’t present yet, but are being worked on), the ability to read data in from a file, the ability to send out “not there” replies, a strong random number generator, timestamp support, and the ability to ask for either A (IPv4 IP) or AAAA (IPv6 IP) records from other DNS servers.
I have fixed two serious bugs in coLunacyDNS over the last couple of weeks, so this code is still unstable. The nice thing about having a DNS server which can run Lua code while processing a DNS query is that it allows one to implement features MaraDNS does not have, such as split horizon DNS or the ability to load DNS records from a file without having to restart the server. Large block lists (lists of names we do not wish to resolve) take up much less memory when stored using Lua tables than as records in Deadwood’s speed optimized cache.
MaraDNS 3.5.0011 can be downloaded at the usual place.
One issue Lua has which has security implications is that Lua’s hash compression algorithm is vulnerable to collisions, which can result in certain kinds of denial of service attacks.
The standard way to solve these kinds of problems is to use SipHash, which I last looked at back in 2013. So, the first thing I did, after realizing Lua had this issue, was to make patches for both Lua 5.1 and Lua 5.4 which add SipHash support:
The version of SipHash I looked at back in 2013 is called “SipHash 2-4”: 2-4 because it applies two rounds of SipHash’s “compression” function for every eight bytes in the input string, and four rounds of the “compression” function after it finishes receiving input. As it turns out, “SipHash 1-3”, while not an officially sanctioned version of SipHash, is noticeably faster: It only performs one round of the core compression function for each eight bytes in the input string, and three rounds of the compression function after the end of the string.
This is the version of SipHash used by Python, Ruby, and Rust:
Another option for 32-bit processors is HalfSipHash, which is similar to a idea I proposed back in 2013: Run SipHash against 32-bit, instead of 64-bit, words. The official proposal uses different rotation constants than the ones I proposed back in 2013; like my 2013 proposal, this SipHash variant has a key which is only 64 bits in size, which is small enough to be brute force cracked, but that is a non-issue in the typical use case where one can not see the numbers generated by HalfSipHash. HalfSipHash, along with the official SipHash reference code, can be viewed here:
Did you know that all of my blog entries are available in a free to download eBook at https://www.samiam.org/blog/ebooks.html.