Best DNS Servers for FreeBSD

DNS is foundational infrastructure. Every service you run depends on it, and the choice of DNS server affects performance, security, and operational complexity. FreeBSD has excellent DNS server support -- Unbound is in the base system, BIND is a pkg install away, and NSD offers a lean authoritative-only option.

This guide compares the three major DNS servers available on FreeBSD: Unbound, BIND, and NSD. We cover their architecture, when to use each, DNSSEC support, configuration complexity, and performance characteristics.

For a detailed head-to-head between BIND and Unbound, see our BIND vs Unbound on FreeBSD comparison.

TL;DR -- Quick Verdict

For recursive DNS resolution (caching resolver): Unbound. It is in the FreeBSD base system, requires minimal configuration, supports DNSSEC validation out of the box, and is the fastest recursive resolver available.

For authoritative DNS (serving your own zones): NSD for read-only authoritative serving. BIND if you need dynamic DNS updates, complex zone management, or DNSSEC signing with automatic key rollover.

Best practice in 2026: Run Unbound for recursive resolution on one machine and NSD or BIND for authoritative serving on another. Never combine both roles in one process.

Understanding DNS Server Roles

Before comparing tools, it is critical to understand the two distinct DNS roles:

Recursive resolver (caching resolver): Receives queries from clients, resolves them by walking the DNS hierarchy from root servers down, caches results, and returns answers. This is what your LAN clients talk to.

Authoritative server: Holds the definitive records for domains you own and answers queries about those domains from other DNS servers on the Internet. This is what the world queries to find your mail server, web server, etc.

|---|---|---|---|

| Recursive resolver | Yes (primary purpose) | Yes | No |

| Both roles | No | Yes (not recommended) | No |

DNS Server Comparison

|---|---|---|---|

| DNSSEC signing | No | Yes | Via ldns-signzone |

| DNS-over-TLS | Yes | Yes | Yes (since NSD 4.6) |

| Multi-threaded | Yes | Yes | Yes |

| Dynamic updates | No | Yes (nsupdate) | No |

| Views/split-horizon | No | Yes | No |

| Response rate limiting | Yes | Yes | Yes |

| RPZ (Response Policy Zones) | Yes | Yes | No |

| TSIG zone transfers | N/A | Yes | Yes |

| Attack surface | Low | Higher | Low |

Unbound

Unbound is a recursive, validating DNS resolver developed by NLnet Labs. It has been included in the FreeBSD base system since FreeBSD 10 and requires no installation.

Setup

Unbound is ready to use immediately. Enable it and configure:

sh
# Enable Unbound in rc.conf
sysrc local_unbound_enable="YES"

# Start with automatic configuration
service local_unbound start

For custom configuration, edit /var/unbound/unbound.conf:

sh
server:
    interface: 0.0.0.0
    interface: ::0
    access-control: 10.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    access-control: 127.0.0.0/8 allow

    # Performance tuning
    num-threads: 4
    msg-cache-slabs: 4
    rrset-cache-slabs: 4
    infra-cache-slabs: 4
    key-cache-slabs: 4
    msg-cache-size: 128m
    rrset-cache-size: 256m

    # Security
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes

    # DNSSEC validation
    auto-trust-anchor-file: "/var/unbound/root.key"

    # DNS-over-TLS forwarding (optional)
    # forward-zone:
    #     name: "."
    #     forward-tls-upstream: yes
    #     forward-addr: 1.1.1.1@853#cloudflare-dns.com
    #     forward-addr: 9.9.9.9@853#dns.quad9.net

    # Local overrides
    local-zone: "internal.example.com." static
    local-data: "server1.internal.example.com. A 10.0.0.10"
    local-data: "server2.internal.example.com. A 10.0.0.11"

Strengths

In the FreeBSD base system. No packages to install.
Minimal configuration for a fully functional caching resolver.
Built-in DNSSEC validation with automatic trust anchor management.
DNS-over-TLS and DNS-over-HTTPS support.
Low memory footprint.
Small, auditable codebase.
Response Policy Zones (RPZ) for DNS-based ad/malware blocking.

Weaknesses

Cannot serve authoritative zones (local-data is for overrides only, not production zones).
No dynamic DNS updates.
No views or split-horizon DNS.

Best For

LAN caching resolvers, DNSSEC-validating resolvers, DNS-over-TLS/HTTPS gateways, privacy-focused DNS, Pi-hole-style DNS filtering.

BIND 9

BIND (Berkeley Internet Name Domain) is the original DNS server and remains the most feature-complete DNS implementation. BIND 9, maintained by ISC, can serve as a recursive resolver, authoritative server, or both.

Setup

sh
# Install BIND 9
pkg install bind918

# Enable BIND
sysrc named_enable="YES"

# Start BIND
service named start

Example authoritative zone configuration in /usr/local/etc/namedb/named.conf:

sh
options {
    directory "/usr/local/etc/namedb/working";
    pid-file "/var/run/named/pid";
    listen-on { any; };
    listen-on-v6 { any; };

    # Disable recursion for authoritative-only server
    recursion no;

    # DNSSEC
    dnssec-validation auto;

    # Rate limiting
    rate-limit {
        responses-per-second 10;
    };
};

zone "example.com" {
    type primary;
    file "/usr/local/etc/namedb/primary/example.com.zone";
    allow-transfer { 198.51.100.2; };  # Secondary NS
    also-notify { 198.51.100.2; };
};

zone "0.168.192.in-addr.arpa" {
    type primary;
    file "/usr/local/etc/namedb/primary/192.168.0.rev";
};

Zone file /usr/local/etc/namedb/primary/example.com.zone:

sh
$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
            2026040901  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            86400 )     ; Negative Cache TTL

    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.
    IN  MX  10 mail.example.com.
    IN  A   203.0.113.10
    IN  AAAA    2001:db8::10

ns1 IN  A   203.0.113.1
ns2 IN  A   198.51.100.2
mail    IN  A   203.0.113.20
www IN  CNAME   @

Strengths

Most feature-complete DNS server available.
Can do everything: authoritative, recursive, DNSSEC signing, views, dynamic updates.
DNSSEC key management with automatic key rollover (dnssec-policy).
Views for split-horizon DNS (serve different answers based on client IP).
Dynamic DNS updates via nsupdate (useful for DHCP integration).
Massive documentation and community knowledge base.

Weaknesses

Large codebase, larger attack surface.
Complex configuration with many options.
Higher memory usage than Unbound or NSD.
Using it for both recursive and authoritative is a bad practice (but people do it).

Best For

Authoritative DNS with complex requirements, DNSSEC signing, dynamic DNS, split-horizon DNS, environments needing views or TSIG-authenticated transfers.

NSD

NSD (Name Server Daemon) is an authoritative-only DNS server developed by NLnet Labs (same team as Unbound). It is designed to do one thing -- serve authoritative DNS -- and do it exceptionally well.

Setup

sh
# Install NSD
pkg install nsd

# Enable NSD
sysrc nsd_enable="YES"

Configuration in /usr/local/etc/nsd/nsd.conf:

sh
server:
    ip-address: 0.0.0.0
    ip-address: ::0
    port: 53
    server-count: 4
    hide-version: yes
    identity: ""
    zonesdir: "/usr/local/etc/nsd/zones"

zone:
    name: "example.com"
    zonefile: "example.com.zone"
    notify: 198.51.100.2 NOKEY
    provide-xfr: 198.51.100.2 NOKEY

zone:
    name: "0.168.192.in-addr.arpa"
    zonefile: "192.168.0.rev"

Strengths

Purpose-built for authoritative DNS. No recursive code, smaller attack surface.
Very fast for zone serving (optimized data structures).
Low memory usage.
Simple configuration.
Pre-compiled zone files for fast startup.
Pairs perfectly with Unbound for a resolver+authoritative architecture.

Weaknesses

Authoritative only. Cannot resolve queries for clients.
No dynamic DNS updates (zones are static files).
DNSSEC signing must be done externally (ldns-signzone or OpenDNSSEC).
No views or split-horizon.

Best For

Authoritative DNS serving for domains you own, secondary DNS servers, environments that pair NSD with Unbound.

DNSSEC Support Comparison

|---|---|---|---|

For DNSSEC signing, BIND is the simplest path. Its dnssec-policy feature handles key generation, rotation, and signing automatically:

sh
# BIND 9 DNSSEC policy in named.conf
dnssec-policy "standard" {
    keys {
        ksk key-directory lifetime unlimited algorithm ecdsap256sha256;
        zsk key-directory lifetime P90D algorithm ecdsap256sha256;
    };
};

zone "example.com" {
    type primary;
    file "primary/example.com.zone";
    dnssec-policy "standard";
    inline-signing yes;
};

Architecture Recommendations

Small Network (Home/Small Office)

Run Unbound as a caching resolver. No authoritative server needed -- use your registrar's DNS or a hosted DNS service (Cloudflare, Route 53) for your domains.

shell
Clients -> Unbound (local resolver) -> Internet

Medium Network (Office/Small ISP)

Run Unbound for recursive resolution. Run NSD (or BIND) for authoritative serving of your domains on separate machines.

shell
Internal clients -> Unbound (recursive resolver)
External queries -> NSD (authoritative for your zones)

Large Network (ISP/Enterprise)

Multiple Unbound instances behind a load balancer for recursive resolution. BIND or NSD for authoritative serving with primary/secondary replication. DNSSEC signing on the primary.

shell
Internal clients -> Load Balancer -> Unbound cluster
External queries -> Anycast -> NSD/BIND cluster (primary + secondaries)

Performance Comparison

Approximate benchmarks for a FreeBSD server with 4 cores and 8 GB RAM, using dnsperf:

|---|---|---|---|---|

| Cached queries/sec | ~200,000 | ~120,000 | N/A | N/A |

| Authoritative queries/sec | N/A | N/A | ~150,000 | ~250,000 |

| Memory (idle) | ~50 MB | ~120 MB | ~80 MB | ~30 MB |

| Memory (loaded) | ~300 MB | ~500 MB | ~200 MB | ~100 MB |

These numbers vary significantly based on zone count, cache size, and query patterns. They illustrate relative performance, not absolute limits.

FAQ

Should I use BIND or Unbound on FreeBSD?

For recursive resolution (caching resolver for your network), use Unbound. It is faster, simpler, and included in the base system. For authoritative serving (hosting zones for your domains), use BIND or NSD. Do not use BIND for recursive resolution in 2026 unless you have a specific reason.

Is NSD better than BIND for authoritative DNS?

NSD is faster and simpler for static authoritative DNS serving. BIND is better if you need dynamic updates, DNSSEC inline signing, views, or complex zone management. For most authoritative use cases, NSD is the better choice paired with external DNSSEC signing.

Can Unbound replace BIND on FreeBSD?

For recursive resolution, yes -- it is strictly better. For authoritative DNS, no -- Unbound does not serve authoritative zones. You need BIND or NSD for that role.

How do I set up DNSSEC on FreeBSD?

For validation (verifying DNSSEC signatures on queries): enable Unbound with auto-trust-anchor-file -- this is the default. For signing (signing your own zones): use BIND's dnssec-policy for the simplest path, or use ldns-signzone with NSD for a lighter approach.

What is the best DNS server for a FreeBSD firewall/router?

Unbound. It is already in the base system, lightweight, supports DNSSEC validation, and can serve local overrides. If you are running pfSense or OPNsense (both FreeBSD-based), Unbound is already the default resolver.

Can I use Unbound to block ads and malware?

Yes. Use Response Policy Zones (RPZ) to block domains. Download regularly updated blocklists and configure them as RPZ feeds. This provides Pi-hole-like functionality using only Unbound.

sh
# In unbound.conf, add an RPZ feed
rpz:
    name: "rpz.example.com"
    zonefile: "/var/unbound/rpz-blocklist.zone"
    rpz-log: yes
    rpz-log-name: "rpz-block"