Linux DNS Server Configuration – Detailed Guide 2026

Linux DNS Server Configuration is the process of installing, securing, and tuning a DNS service (e.g., BIND or Unbound) on Linux to resolve or authoritatively answer domain queries. It includes planning zones, creating records, setting access controls, enabling DNSSEC, opening port 53 (UDP/TCP), adding secondaries, and validating with dig, delv, and logs.

If you want reliable name resolution for websites, mail, and internal services, mastering Linux DNS Server Configuration is essential. This guide explains, step by step, how to plan, deploy, secure, and optimize authoritative and recursive DNS on modern Linux distributions in 2026, using battle tested configurations and real world hosting experience.

---

What DNS is and Why it Matters

The Domain Name System (DNS) maps human friendly names (example.com) to IP addresses. Every web request, API call, and email delivery depends on DNS.

A well configured Linux DNS server improves performance, reliability, and security for your network and applications.

Authoritative vs. Recursive (Caching) DNS

Before you configure anything, decide your role:

• Authoritative server: Hosts your zones and returns final answers for your domains (A, AAAA, MX, TXT, etc.).
• Recursive (caching) resolver: Finds answers on behalf of clients by querying the internet and caches results to speed up subsequent lookups.

Many organizations run both: a public authoritative pair for their domains and internal caching resolvers for users and servers.

---

Plan Your Architecture First

Good planning prevents outages. Define scope and security from day one.

Key decisions

• Role: Authoritative, recursive, or split (using views for internal/external).
• Platforms: Ubuntu 22.04/24.04 LTS, Debian 12, RHEL/Rocky/Alma 9.
• Topology: Two+ geographically separate authoritative nameservers; one or more internal resolvers (anycast if possible).
• Zones and records: Choose naming, TTLs (typically 300–3600s), and a serial policy (YYYYMMDDnn).
• Security: ACLs, TSIG keys for transfers, DNSSEC signing, response rate limiting (RRL), minimal responses, and logging.

Prerequisites and networking

• Open port 53 UDP/TCP on firewalls and any load balancers.
• Ensure time sync (chrony) and stable hostnames.
• Harden OS: least privilege, patches, AppArmor/SELinux profiles.
• Use static IPs (IPv4 and IPv6) for authoritative servers.

---

Option A: Configure a Caching Resolver with Unbound

Unbound is a secure, lightweight recursive resolver with DNSSEC validation and QNAME minimization by default—ideal for internal networks.

Install Unbound

# Ubuntu/Debian
sudo apt update && sudo apt install -y unbound

# RHEL/Rocky/Alma
sudo dnf install -y unbound

Minimal Unbound configuration

Create or edit /etc/unbound/unbound.conf (paths vary by distro). This example enables DNSSEC, access control, and optional forwarders.

server:
  username: "unbound"
  directory: "/etc/unbound"
  interface: 0.0.0.0
  interface: ::0
  access-control: 10.0.0.0/8 allow
  access-control: 172.16.0.0/12 allow
  access-control: 192.168.0.0/16 allow
  access-control: 127.0.0.0/8 allow
  access-control: ::1 allow
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes

  # Security and privacy
  harden-glue: yes
  harden-dnssec-stripped: yes
  qname-minimisation: yes
  hide-identity: yes
  hide-version: yes
  rrset-roundrobin: yes

  # Performance
  cache-min-ttl: 60
  cache-max-ttl: 86400
  msg-cache-size: 64m
  rrset-cache-size: 128m
  num-threads: 2

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

# Optional: Forward to upstream (e.g., your ISP or public resolvers)
# Set to your preferred forwarders if you don't want full recursion
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

Start and enable the service, then validate:

sudo systemctl enable --now unbound
unbound-checkconf
dig @127.0.0.1 youstable.com +dnssec
delv youstable.com

Firewall and SELinux

# UFW
sudo ufw allow 53
sudo ufw status

# firewalld
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

# SELinux (RHEL family) - Unbound default policy is usually sufficient
sudo getenforce
# If enforcing breaks DNS unexpectedly, review AVC logs before changing mode

---

Option B: Configure an Authoritative Server with BIND 9

BIND 9 remains the most common authoritative DNS on Linux. The following configuration targets BIND 9.18+ LTS, widely available across distributions in 2026.

Install BIND

# Ubuntu/Debian
sudo apt update && sudo apt install -y bind9 bind9-utils

# RHEL/Rocky/Alma
sudo dnf install -y bind bind-utils

Global options (named.conf.options)

On Debian/Ubuntu, edit /etc/bind/named.conf.options. On RHEL-like systems, use /etc/named.conf. Adjust IPs and ACLs to your environment.

options {
  directory "/var/cache/bind";
  listen-on { any; };
  listen-on-v6 { any; };

  // Authoritative only: no recursion
  recursion no;
  allow-query { any; };
  allow-transfer { none; }; // override per-zone when using secondaries

  // Hardening
  minimal-responses yes;
  rate-limit {
    responses-per-second 25;
  };
  dnssec-enable yes;
  dnssec-validation yes;

  // Logging (basic)
  querylog yes;
};

logging {
  channel default_log {
    file "/var/log/named/named.log" versions 5 size 10m;
    severity info;
    print-time yes;
  };
  category default { default_log; };
  category queries { default_log; };
};

Create a forward zone (example.com)

Add a zone clause and a zone file. Replace IPs, hosts, and mail records with your real values.

// named.conf.local (Debian/Ubuntu) or appended to /etc/named.conf on RHEL
zone "example.com" {
  type master;
  file "/etc/bind/zone.example.com"; // RHEL: /var/named/zone.example.com
  allow-transfer { 203.0.113.53; 2001:db8::53; }; // secondaries
  also-notify { 203.0.113.53; 2001:db8::53; };
  inline-signing yes;    // for DNSSEC (optional now; see DNSSEC section)
  auto-dnssec maintain;  // enables automatic signing/rollover
};

$TTL 300
@   IN SOA ns1.example.com. admin.example.com. (
      2026010101 ; serial YYYYMMDDnn
      3600       ; refresh
      600        ; retry
      1209600    ; expire
      300 )      ; minimum

    IN NS   ns1.example.com.
    IN NS   ns2.example.com.

; A/AAAA records
ns1 IN A     198.51.100.10
ns1 IN AAAA  2001:db8:10::10
ns2 IN A     203.0.113.53
ns2 IN AAAA  2001:db8:53::53
@   IN A     198.51.100.20
@   IN AAAA  2001:db8:20::20
www IN CNAME @

; Mail
@   IN MX 10 mail.example.com.
mail IN A    198.51.100.30
mail IN AAAA 2001:db8:30::30

; Verification / policy
@   IN TXT "v=spf1 a mx ~all"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
; Add DKIM TXT via your MTA tooling

; SRV example (SIP)
_sip._tcp IN SRV 10 60 5060 sip1.example.com.
sip1 IN A 198.51.100.40

Create a reverse zone (203.0.113.0/24)

zone "113.0.203.in-addr.arpa" {
  type master;
  file "/etc/bind/zone.203.0.113.rev";
};

; /etc/bind/zone.203.0.113.rev
$TTL 300
@ IN SOA ns1.example.com. admin.example.com. (
     2026010101 3600 600 1209600 300 )
  IN NS ns1.example.com.
  IN NS ns2.example.com.

10  IN PTR ns1.example.com.
20  IN PTR example.com.
30  IN PTR mail.example.com.

Validate and start BIND

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zone.example.com
sudo named-checkzone 113.0.203.in-addr.arpa /etc/bind/zone.203.0.113.rev

sudo systemctl enable --now named    # RHEL
sudo systemctl enable --now bind9    # Debian/Ubuntu

dig @127.0.0.1 example.com A
dig @127.0.0.1 -x 198.51.100.20

Registrar and glue

Create nameserver hosts (ns1/ns2) with glue A/AAAA at your registrar, then set your domain to use those nameservers. Propagation typically completes within minutes to 48 hours depending on registry and TTLs.

Split Horizon (Views) for Internal vs. External

Views serve different answers to different clients, ideal for exposing public records while keeping internal IPs private.

acl "internal_nets" { 10.0.0.0/8; 192.168.0.0/16; };

view "internal" {
  match-clients { "internal_nets"; };
  recursion yes; // if you also want to resolve for internal users
  zone "example.com" {
    type master;
    file "/etc/bind/zone.example.com.internal";
  };
};

view "external" {
  match-clients { any; };
  recursion no;
  zone "example.com" {
    type master;
    file "/etc/bind/zone.example.com";
  };
};

Enable DNSSEC on Authoritative Zones

DNSSEC prevents spoofing by signing your records. With inline signing and auto dnssec maintain, BIND manages keys automatically.

# Ensure these are set in zone config:
# inline-signing yes;
# auto-dnssec maintain;

# Generate keys (if not auto-created)
cd /var/cache/bind
sudo rndc loadkeys example.com

# Check status
sudo rndc signing -list example.com
dig +dnssec example.com DS @ns1.example.com

After DS records appear in your signed zone, publish the DS at your registrar so resolvers can validate your domain.

Zone Transfers and Secondaries

Always run at least one secondary nameserver on a separate network or region. Secure transfers with TSIG.

key "xfr-key" {
  algorithm hmac-sha256;
  secret "YOUR_BASE64_SECRET";
};

server 203.0.113.53 {
  keys { "xfr-key"; };
};

zone "example.com" {
  type master;
  file "/etc/bind/zone.example.com";
  allow-transfer { key "xfr-key"; 203.0.113.53; };
  also-notify { 203.0.113.53; };
  notify yes;
};

---

Hardening and Best Practices (2026)

• Limit surface: Disable recursion on public authoritative servers.
• RRL and minimal responses: Reduce amplification risk.
• QNAME minimization (Unbound default, BIND supports): Increase privacy.
• Monitor logs and queries: Use journald, BIND logs, and metrics exporters.
• Keep packages updated: BIND 9.18+ or current LTS; Unbound latest stable.
• Use IPv6 alongside IPv4 and ensure glue for both.
• Set sane TTLs: 300–600s for fast moving records; 3600-14400s for stable ones.
• Document serial changes and automate with CI/CD to avoid stale zones.

Troubleshooting Checklist

• SERVFAIL on signed domains: Check DS mismatch or expired keys with delv.
• NXDOMAIN vs. NOERROR: Validate zone content with named checkzone.
• Stale answers: Lower TTLs and flush caches (rndc flush; unbound control flush_zone).
• Transfers failing: Verify TSIG, open TCP/53, and allow transfer ACLs.
• No external reachability: Confirm public firewall/NAT allows UDP/TCP 53.

Point Linux Hosts to Your New Resolver

Modern distributions manage resolv.conf via systemd resolved or NetworkManager. Configure using the appropriate tool instead of editing resolv.conf directly.

systemd resolved (Ubuntu/Debian)

# Netplan example (Ubuntu)
# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    ens18:
      addresses: [192.0.2.10/24]
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [10.0.0.53, 2001:db8::53]

sudo netplan apply
resolvectl status

NetworkManager (RHEL/Rocky/Alma)

nmcli con mod eth0 ipv4.dns "10.0.0.53" ipv4.ignore-auto-dns yes
nmcli con mod eth0 ipv6.dns "2001:db8::53" ipv6.ignore-auto-dns yes
nmcli con up eth0
resolvectl status

Real World Tips from Hosting Operations

• Hidden master pattern: Keep master behind a firewall; expose only secondaries publicly.
• Anycast for resolvers: Improves latency and resilience for internal users.
• Staging zones: Test new records on a subdomain before production.
• Lower TTL before migrations: Drop to 60–120s 24 hours prior, then raise after cutover.
• Query blackholing: Block abusive clients at firewall and via BIND ACLs.

When to Choose Managed DNS or Managed Servers

Running DNS in house offers control, but it requires vigilance: security patches, 24×7 monitoring, and careful change management. If you prefer to focus on apps, consider managed DNS or a managed VPS/Dedicated server. YouStable provides performance optimized VPS and dedicated servers with expert support, and can help you deploy secure, high availability DNS aligned with best practices.

---

FAQs

---

Conclusion

With careful planning, hardened configs, and continuous monitoring, Linux DNS Server Configuration delivers fast, secure, and resilient name services. Use Unbound for internal caching, BIND for authoritative zones, enable DNSSEC, add secondaries, and automate changes. If you need help or prefer a managed approach, YouStable’s hosting experts can deploy and maintain a production grade DNS stack for you.