DNS Software

The software behind the infrastructure

Every DNS query is answered by software running on a server. The choice of DNS software determines performance, security, features, and operational complexity. Unlike most infrastructure software categories — where a single dominant product captures the market — DNS has a rich ecosystem of competing implementations, each with distinct design philosophies.

The split is fundamental: authoritative servers answer questions about zones they are responsible for, and recursive resolvers chase referrals across the hierarchy to find answers for clients. Some software does both; most modern implementations specialize in one role.

BIND: the original and still the most deployed

BIND (Berkeley Internet Name Domain) is the oldest, most widely deployed, and most influential DNS software ever written. Four graduate students at UC Berkeley — Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou — wrote the first version in 1984 under a DARPA grant. It shipped with 4.3BSD and became the de facto DNS implementation for the early internet.

Attribute	Detail
First release	1984
Current version	9.20+
Language	C
License	Mozilla Public License 2.0
Maintained by	Internet Systems Consortium (ISC)
Capabilities	Authoritative + recursive

BIND’s evolution spans four major generations. BIND 4 (maintained by Paul Vixie from 1988) was the version that ran the early internet. BIND 8 (mid-1990s) was a major rewrite by Vixie and Bob Halley. BIND 9 (2000) was a complete ground-up rewrite funded by a consortium of companies, designed for security and extensibility. BIND 9 remains the current major version, now past 9.20.

ISC, the non-profit that maintains BIND, operates on approximately $7.7 million in annual revenue (2024) and employs 16 BIND engineers out of 45 total staff. ISC also operates F-root, one of the 13 root servers.

BIND’s market share has declined from its estimated 75%+ in the 2000s, but it remains the most widely used open-source DNS software globally. It is the reference implementation — when an RFC is published, BIND is typically the first to implement it.

Unbound: the validating resolver

Unbound, developed by NLnet Labs in the Netherlands, is a recursive-only resolver focused on security and performance. Released in 2007, it was designed from the start as a DNSSEC-validating resolver — DNSSEC was an afterthought bolted onto BIND, but it’s core to Unbound’s architecture.

Attribute	Detail
First release	2007
Language	C
License	BSD
Maintained by	NLnet Labs (Amsterdam)
Capabilities	Recursive only

Unbound has become the default resolver in FreeBSD and OpenBSD, and it’s the recommended upstream resolver for Pi-hole deployments seeking full DNS privacy. It supports DNS over TLS, DNS over HTTPS, DNS over QUIC, and aggressive NSEC caching (RFC 8198) that reduces unnecessary queries for non-existent names.

Its modular architecture allows features to be compiled in or out, and it supports a Python module interface for custom logic. Unbound cannot serve authoritative zones — if you need both roles, you pair it with NSD.

PowerDNS: the database-backed alternative

PowerDNS, created by Bert Hubert in the Netherlands in 2000 and open-sourced in 2002, took a fundamentally different approach: instead of reading zone files from disk, PowerDNS can serve DNS data from any database backend — MySQL, PostgreSQL, SQLite, LDAP, Lua scripts, or plain files.

Attribute	Detail
First release	2000 (open-sourced 2002)
Language	C++
License	GPL v2
Currently owned by	Open-Xchange
Capabilities	Split: Authoritative Server + Recursor + DNSdist (load balancer)

PowerDNS’s architecture is split into three components:

• PowerDNS Authoritative Server — Serves zones from pluggable backends. Supports over a dozen database backends.
• PowerDNS Recursor — A high-performance recursive resolver, separate from the authoritative server.
• DNSdist — A DNS-aware load balancer and traffic manager.

The database-backed model makes PowerDNS attractive for hosting companies and ISPs that manage millions of zones. Updating a DNS record means updating a database row — no zone file editing, no serial number incrementing, no reload commands. PowerDNS serves 14+ million domains and 400+ million subscribers through ISPs that use it as their infrastructure.

PowerDNS claims zero major support cases in over 10 years of deployment — a remarkable reliability record.

CoreDNS: the cloud-native server

CoreDNS is the DNS server for the cloud-native era. Written in Go by Miek Gieben (a Google SRE), it launched in March 2016, became a CNCF project in 2017, and graduated to CNCF’s top maturity level in January 2019. Since Kubernetes 1.13, CoreDNS is the default DNS server in every Kubernetes cluster.

Attribute	Detail
First release	2016
Language	Go
License	Apache 2.0
Maintained by	CNCF community
GitHub stars	~13,800

CoreDNS was created by forking the Caddy web server and replacing HTTP handling with DNS handling. This gave it Caddy’s plugin architecture — CoreDNS is built entirely from plugins (called “plugins” in its Corefile configuration). Want to forward queries? Add the forward plugin. Want to cache? Add cache. Want to serve from etcd? Add etcd.

This plugin model makes CoreDNS extraordinarily flexible. It can act as an authoritative server, a forwarding resolver, a service discovery endpoint, or a custom DNS middleware — all configured by composing plugins.

Gieben also wrote miekg/dns, the most widely used DNS library in Go, which underpins CoreDNS and countless other Go DNS tools.

Knot DNS and Knot Resolver

CZ.NIC, the Czech domain registry, develops two separate DNS implementations:

Knot DNS is a high-performance authoritative-only server. It runs on three root servers (B, K, and L) and serves the .cz zone. Along with NSD, it can handle an order of magnitude more queries than BIND for authoritative workloads.

Knot Resolver is a recursive resolver that powers Cloudflare’s 1.1.1.1 — the fastest public resolver globally. It’s built on a different codebase from Knot DNS and uses LuaJIT for extensibility.

Software	Type	License	Root servers
Knot DNS	Authoritative	GPL v3+	B, K, L
Knot Resolver	Recursive	GPL v3+	None (but powers Cloudflare 1.1.1.1)

NSD: the authoritative specialist

NSD (Name Server Daemon), developed by NLnet Labs in cooperation with RIPE NCC, is a pure authoritative server designed to increase software diversity away from BIND. First deployed in 2003, it was the software chosen when K-root became the first root server to break from BIND — a watershed moment for the DNS ecosystem.

NSD reads BIND-compatible zone files and compiles them to a binary format for fast startup. It does not support recursion by design — it does one thing and does it extremely well. Four root servers now run NSD.

The rest of the ecosystem

dnsmasq — A lightweight DNS forwarder and DHCP server by Simon Kelley, started as a hobby project for his home Linux network around 2000. It is now embedded in billions of devices: consumer routers, Android phones (until Android 10), Docker’s internal DNS, and libvirt/KVM. dnsmasq does not perform full recursive resolution — it forwards queries to an upstream resolver and caches the results.

djbdns — Created by Daniel J. Bernstein in the late 1990s out of frustration with BIND’s security vulnerabilities. djbdns implemented UDP port randomization in its first release (December 1999) — a decade before the Kaminsky vulnerability made it critical. Bernstein offered a $1,000 bounty for any security hole; it was finally awarded in March 2009. djbdns was released into the public domain in 2007 but is no longer actively developed.

Pi-hole and AdGuard Home — DNS sinkholes that act as network-wide ad blockers by comparing queries against blocklists and returning dummy responses for advertising and tracking domains. Pi-hole (~50k GitHub stars) runs primarily on Raspberry Pi hardware; AdGuard Home (~31k stars) is cross-platform and includes native DoH/DoQ support.

Software diversity matters

The DNS root server system deliberately avoids monoculture. The 13 root servers run a mix of BIND, NSD, Knot DNS, and custom implementations. If a critical vulnerability were discovered in BIND, root servers running NSD and Knot would be unaffected. If NSD had a bug, BIND-based roots would continue operating.

This principle extends beyond root servers. The DNS ecosystem benefits from having multiple independent implementations of the same protocol. Implementation diversity means that a bug in one codebase doesn’t take down the entire infrastructure — the same resilience strategy that makes the root server system robust applies to the software layer.

Software	Root server use	Notable deployments
BIND	F-root, others	Reference implementation, most ISPs
NSD	D, K, L roots	ccTLDs, critical infrastructure
Knot DNS	B, K, L roots	.cz, high-performance zones
Knot Resolver	—	Cloudflare 1.1.1.1
CoreDNS	—	Every Kubernetes cluster
Unbound	—	FreeBSD, OpenBSD default
PowerDNS	—	14M+ domains, hosting companies