Conversation with Gemini

Because BIND handles both authoritative (serving your own domain records) and recursive (resolving queries for client devices) DNS, the "best" replacement depends on which role you need to fill.

Modern network architecture heavily favors separating these two roles for better security, performance, and stability.

Comparison of Top Alternatives

Which Should You Choose?

1. If you need a local or enterprise Recursive Resolver

• Choose Unbound: Developed by NLnet Labs specifically to replace BIND's resolver functionality. It is fast, security-focused, extremely stable, and the default resolver in systems like FreeBSD and PfSense.

• Choose PowerDNS Recursor: If you need advanced traffic filtering, custom query rewriting, or Lua scripting at scale.

2. If you need an Authoritative DNS Server

• Choose NSD: Also by NLnet Labs, NSD is built purely to serve zone files as fast as possible without the bloat of recursion.

• Choose PowerDNS Authoritative: If you store zone data in SQL databases (MySQL, PostgreSQL) or want to manage zones dynamically via a REST API.

• Choose Knot DNS: If you require maximum performance for huge zone counts or high query volumes.

3. If you operate in Containers or Kubernetes

• Choose CoreDNS: CoreDNS replaced SkyDNS as the default internal DNS server for Kubernetes. It uses plugins to seamlessly integrate with cloud providers, ETCD, and Kubernetes APIs.

Summary Recommendation

• For simple, secure caching/resolving: Replace BIND with Unbound.

• For static zone file hosting: Replace BIND with NSD.

• For complex database-driven or ISP infrastructure: Replace BIND with PowerDNS.

If you need both roles on the same infrastructure, you have two primary approaches: running a split-architecture setup with dedicated lightweight tools on separate IP addresses/ports, or using a single dual-role server like PowerDNS.

Option 1: The Modern Best Practice (NSD + Unbound)

Running separate dedicated daemons on the same machine is the industry standard for security and isolation. NSD serves your zone data, and Unbound handles external recursion for your clients.

To prevent port conflicts on 53, assign each daemon to a different local IP address or bind interface:

• Authoritative (NSD): Binds to the external IP (or 127.0.0.1:5353) to answer requests for your domain.

• Recursive (Unbound): Binds to internal/LAN interfaces (127.0.0.1:53, local subnet) to handle outgoing queries, forwarding local domain requests to NSD.

 Client Query
      │
      ▼
┌──────────────┐   Local Domain   ┌──────────────┐
│   Unbound    │ ────────────────►│     NSD      │
│ (Recursive)  │   (port 5353)    │(Authoritative│
└──────────────┘                  └──────────────┘
      │
      │ External Domain
      ▼
   Internet

Why split them?

• Security: Prevents cache poisoning, reflection attacks, and accidental open recursion.

• Privilege Separation: NSD runs completely chrooted with no outward network connections required.

• Performance: Neither daemon competes for memory or lock cycles between cache storage and zone updates.

Option 2: The Unified Suite (PowerDNS)

If you prefer managing software from a single project ecosystem, PowerDNS provides two purpose-built engines designed to run side-by-side:

• PowerDNS Authoritative Server: Handles domain hosting with options for flat zone files, SQL backends (MySQL/PostgreSQL), or REST APIs.

• PowerDNS Recursor: Handles caching and client resolution, with powerful Lua scripting capabilities.

Like the NSD/Unbound setup, both binaries run as separate services bound to distinct IPs or ports, but share similar configuration styles, logging patterns, and management tools.

Option 3: Dual-Role Monolith (Knot DNS / BIND)

If you strictly want one single process answering both types of queries from a single configuration file without running two services:

• Knot Resolver: Can handle recursion while serving authoritative local zones using the modules = { 'hints' } or zone loading features.

• BIND 9: Remains the primary single-process server natively supporting simultaneous authoritative and recursive operations.

Important: If using a single process for both roles, restrict recursive access strictly to trusted local IP ranges using ACLs (e.g., allow-recursion { 192.168.1.0/24; localhost; };) to prevent turning your server into an open resolver.