Update #1: op-nslookup

Photo by Chris Liverani on Unsplash

This is an update on Journey to new DNS servers, which I am now calling op-nslookup

I was playing around with PowerDNS on one of my existing servers, using a separate port, then ran simple dig queries and wanted to see what the difference would be. TL;DR: I wasn’t impressed.

What did I try:

  • I installed PowerDNS 4.6 server from their official repo, on an Ubuntu 18.04 server (yeah, I know).
  • Modified the pdns.conf file and set the existing named.conf file for the bind backend, so it loads the existing zones
  • Run zone2sql into an sqlite3 file, and configure gsqlite3 backend

In both cases (bind or gsqlite3 as backends) the performance was the same, I managed to tune the performance so the average of the query time was on par with the existing bind.

The bad part here was that while the minimum was the same (120-124ms) the maximum was way higher for PowerDNS (400ms 600ms while Bind was usually up to 300ms) so I think my numbers are not very scientific and if I want to be sure I’ll need to benchmark using a reliable tool and not simply run and copy-paste into calc…

But this isn’t all and I will definitely need to invest more time in comparing features, since I am sure there are configurations at which I can get more out of it, even in speed wise.

The fact this is a hobby project does not mean I need to lower my standards.

Journey to new DNS servers

Photo by Taylor Vick on Unsplash

I have been managing my own DNS servers for a long time now, most of the time using ISPConfig to manage two to three BIND instances. It has been fun, but I got tired of ISPConfig’s limitations in some areas, and I want to have my own definition of servers.

I have tried that before, several times, but I did the mistake so many did before, trying to solve everything in one shot. And learning from my paid work experience, it isn’t worth the time. So I am going on a new journey to build my own infrastructure, starting with my self-hosted DNS servers, one piece of the infrastructure at a time.

It might take time, and I am aware that sometimes it’ll be days and weeks between progresses, but it is a journey of learning and sharing. So let’s begin.

My considerations

  1. Quick response
  2. Quick refresh (of changes)
  3. Support many resource records types and security measures
  4. Ability to support DDNS
  5. Active maintainers

Quick response

If I am in the US and the server is in Europe, a 100ms response time in the server itself is really slow. The server must respond very quickly to each request.

Quick refresh

When a change is introduced, a 60 seconds to update is slow, think about APIs updating DNS records for verification purposes, it needs to go to the next step within that timeframe. So my goal is up to 20 seconds to implement record changes.

Support many RR types and security

I expect the server to support most of the RR types, namely support:

  • Implement some ANAME behavior (Like CNAME, but can be used for the apex domain)
  • CAA

It should fully support DNSSEC with the latest practices

Active maintainers

The program I will choose should be actively maintained, otherwise any bug report, feature request or merge request might just remain in limbo, and I will either have to fork it or move to another solution.


  • BIND 9 (9.16.n for now, it has ESV)
  • PowerDNS

These are the only two after filtering the common available options, given that I already use IPv6 in both serving and records, wild card records and want to use DNSSEC.

I’ll state the obvious, I need the software to be open and free source, be tested and run smoothly on Linux server (I can manage with BSD if that will become a requirement).

Other options

  • Develop my own server

Well, a lovely idea, I always like to consider it in every project, but this isn’t on the table for now, sorry me.

Bu, as a consolation, I will be working on all integration and admin interfaces, and with the slightest hint of trouble using available solutions I’ll just write up my own.

That’s it for now, hitting the road for new DNS servers.