Origins

How came atomdns into existence? As being the author of Go DNS and now Go DNS2, I pondered back in 2016 if I should write a DNS server. Four days later I had a working prototype. This in turn was prompted by a brief involvement in SkyDNS, which was also a very good idea, but the DNS implementation could have been better (hence my involvement).

This eventually morphed in CoreDNS and everything that followed from that. In 2023-ish I stopped doing as much work as I did on CoreDNS, and ceased doing DNS and Go development altogether for a while.

In late 2025 it started itching again and I wanted to improve Go DNS, so I forked it into Go DNS2, and added a lot of things from CoreDNS into dnstest and dnsutil sub-packages. The code was cleaner, faster and uses less memory by improving buffer management, see this feedback for instance. Working on a DNS library, without involving real, running code is a risk, as you may end up making things that are hard to use or don’t work in practice. To prevent this from happening I needed a server, and I wanted a new server, hence atomdns was born.

atomdns is much leaner than CoreDNS, because it better leverages the new code that is now available in Go DNS, it’s also faster because of that. It has the same model, chaining middleware, now called handlers in atomdns. And one other big difference is that the order of handlers in the configuration file matters. As this is the executing order when atomdns is running your handlers.

The focus for atomdns is also much more on running locally, instead of running in the cloud and serving whatever data is available there. In other words: atomdns will never have a Kubernetes handler.