How to Configure DNS on Linux Server – (Step-by-Step Guide 2026)

To configure DNS on a Linux server, install BIND (named), define your DNS role (authoritative, caching, or forwarder), edit named.conf and zone files, open port 53 (TCP/UDP), start and enable the service, then validate with dig/nslookup. This step-by-step 2026 guide covers Ubuntu/Debian and RHEL/Rocky systems with best practices and security tips.

If you’re learning how to configure DNS on Linux server environments, this guide walks you through a clean, reliable setup using BIND9. You’ll learn the difference between authoritative and caching resolvers, how to create zone files, open the right firewall ports, and test your configuration—using clear steps that align with 2026 Linux distributions.

What Is DNS and Why It Matters

Domain Name System (DNS) translates human-readable domain names into IP addresses so browsers, email, and APIs can connect to the correct server. On Linux, DNS is typically provided by BIND (Berkeley Internet Name Domain), the most widely used open-source DNS server. You can run BIND as an authoritative server, a caching resolver, or a secure forwarding server.

Search Intent and What You’ll Learn

This tutorial is a practical, step-by-step Linux DNS server tutorial for beginners and sysadmins who want a robust, production-ready configuration. You will:

• Install and configure BIND9 on Ubuntu/Debian and RHEL/Rocky/CentOS
• Create forward and reverse zone files (A, AAAA, CNAME, MX, NS, PTR)
• Choose authoritative vs caching/forwarder roles
• Open firewall ports and harden DNS (recursion control, logging, optional DNSSEC)
• Troubleshoot with dig, nslookup, and system logs

Prerequisites

• Linux server (Ubuntu 22.04/24.04 or Debian 12; Rocky Linux/RHEL 8/9)
• Root or sudo access
• A public/static IP if hosting an authoritative DNS
• Domain name (if creating public zones) and access to your registrar

Choose Your DNS Role

Before editing configs, decide what your DNS server should do. This affects named.conf and security settings.

• Authoritative DNS: Answers only for zones you host (e.g., example.com). Disable recursion.
• Caching/Recursive Resolver: Answers queries by recursively resolving and caching results for clients. Allow recursion only for trusted subnets.
• Forwarder: Forwards queries to upstream resolvers (ISP, public resolvers) and caches responses.

Step-by-Step: Configure DNS on Linux Server (BIND9)

1) Install BIND on Ubuntu/Debian

sudo apt update
sudo apt install -y bind9 bind9-utils dnsutils
sudo systemctl enable --now bind9
sudo systemctl status bind9

On Ubuntu/Debian, the main configs are under /etc/bind. You’ll typically edit named.conf.options and named.conf.local.

2) Install BIND on RHEL/Rocky/CentOS

sudo dnf install -y bind bind-utils
sudo systemctl enable --now named
sudo systemctl status named

On RHEL-family systems, configs live in /etc/named.conf, and zones are usually stored in /var/named.

3) Base Configuration (Authoritative vs Caching)

Decide your role and update options accordingly. Below are secure defaults for both Debian-based and RHEL-based layouts. Adjust CIDR and IPs for your network.

Ubuntu/Debian: edit /etc/bind/named.conf.options

options {
    directory "/var/cache/bind";

    // Listen on all interfaces (IPv4/IPv6)
    listen-on { any; };
    listen-on-v6 { any; };

    // Example for authoritative-only:
    recursion no;
    allow-query { any; };

    // For caching/recursive mode, use:
    // recursion yes;
    // allow-query { 10.0.0.0/8; 192.168.0.0/16; localhost; };
    // allow-recursion { 10.0.0.0/8; 192.168.0.0/16; localhost; };
    // forwarders { 1.1.1.1; 8.8.8.8; }; // optional forwarders

    dnssec-validation auto;
    auth-nxdomain no;    // conform to RFC1035
    minimal-responses yes;
};

RHEL/Rocky/CentOS: edit /etc/named.conf

options {
    directory "/var/named";
    pid-file "/run/named/named.pid";

    listen-on port 53 { any; };
    listen-on-v6 { any; };

    // Authoritative-only defaults:
    recursion no;
    allow-query { any; };

    // For caching/recursive mode:
    // recursion yes;
    // allow-query { localhost; 10.0.0.0/8; 192.168.0.0/16; };
    // allow-recursion { localhost; 10.0.0.0/8; 192.168.0.0/16; };
    // forwarders { 9.9.9.9; 8.8.4.4; };

    dnssec-validation auto;
    minimal-responses yes;
};

include "/etc/named.rfc1912.zones";

For authoritative servers, ensure recursion no. For caching resolvers, restrict recursion and queries to trusted subnets only.

4) Define Your Zones (Authoritative Setup)

Assume your domain is example.com and your server IP is 203.0.113.10 (IPv4) and 2001:db8::10 (IPv6). We’ll create a forward zone (example.com) and a reverse zone for 203.0.113.0/24.

Ubuntu/Debian: edit /etc/bind/named.conf.local

zone "example.com" IN {
    type master;
    file "/etc/bind/db.example.com";
};

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

RHEL/Rocky/CentOS: edit /etc/named.rfc1912.zones

zone "example.com" IN {
    type master;
    file "db.example.com";
};

zone "113.0.203.in-addr.arpa" IN {
    type master;
    file "db.203.0.113";
};

Create the forward zone file.

$TTL 300
@   IN SOA ns1.example.com. admin.example.com. (
        2026010101 ; Serial (YYYYMMDDNN)
        3600       ; Refresh
        900        ; Retry
        1209600    ; Expire
        300 )      ; Negative Cache TTL

; Nameservers
@       IN NS  ns1.example.com.
@       IN NS  ns2.example.com.

; A/AAAA records
ns1     IN A    203.0.113.10
ns1     IN AAAA 2001:db8::10
ns2     IN A    203.0.113.11
www     IN A    203.0.113.20
@       IN A    203.0.113.20
@       IN AAAA 2001:db8::20

; Mail (MX)
@       IN MX 10 mail.example.com.
mail    IN A    203.0.113.30

; CNAME example
blog    IN CNAME www.example.com.

Create the reverse zone file for IPv4.

$TTL 300
@   IN SOA ns1.example.com. admin.example.com. (
        2026010101
        3600
        900
        1209600
        300 )

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

10  IN PTR ns1.example.com.
11  IN PTR ns2.example.com.
20  IN PTR www.example.com.
30  IN PTR mail.example.com.

Note: Update the serial number on every change. For public authoritative DNS, register your nameserver hostnames (ns1/ns2) and glue records at your domain registrar.

5) Permissions and SELinux (RHEL)

Set proper ownership and SELinux contexts on RHEL-family systems:

sudo chown root:named /var/named/db.example.com /var/named/db.203.0.113
sudo chmod 640 /var/named/db.*
sudo chcon -t named_zone_t /var/named/db.example.com /var/named/db.203.0.113
sudo setsebool -P named_write_master_zones on

6) Validate Configuration and Start/Reload

# Ubuntu/Debian
sudo named-checkconf
sudo named-checkzone example.com /etc/bind/db.example.com
sudo named-checkzone 113.0.203.in-addr.arpa /etc/bind/db.203.0.113
sudo systemctl reload bind9

# RHEL/Rocky/CentOS
sudo named-checkconf /etc/named.conf
sudo named-checkzone example.com /var/named/db.example.com
sudo named-checkzone 113.0.203.in-addr.arpa /var/named/db.203.0.113
sudo systemctl reload named

7) Open Firewall Ports (TCP/UDP 53)

# Ubuntu/Debian with UFW
sudo ufw allow 53/tcp
sudo ufw allow 53/udp
sudo ufw reload

# RHEL/Rocky/CentOS with firewalld
sudo firewall-cmd --add-service=dns --permanent
sudo firewall-cmd --reload

8) Test with dig and nslookup

# Query your authoritative server directly:
dig @203.0.113.10 example.com A +short
dig @203.0.113.10 www.example.com A +short
dig @203.0.113.10 -x 203.0.113.20 +short

# Check NS and SOA:
dig @203.0.113.10 example.com NS +noall +answer
dig @203.0.113.10 example.com SOA +noall +answer

# If caching resolver:
dig @YOUR_DNS_SERVER youstable.com A +stats +trace

If your server itself should use this resolver, set the system resolver accordingly. On systemd-resolved hosts, configure /etc/systemd/resolved.conf and restart systemd-resolved. On other systems, update /etc/resolv.conf with nameserver 127.0.0.1 or your LAN IP.

Common DNS Records Explained

• A: Maps a hostname to an IPv4 address.
• AAAA: Maps a hostname to an IPv6 address.
• CNAME: Alias to another hostname (cannot coexist with other records at the same name).
• MX: Mail exchanger for email routing; points to a hostname with an A/AAAA record.
• NS: Authoritative nameservers for the zone.
• TXT: Arbitrary text (SPF, DKIM, verification).
• PTR: Reverse DNS mapping from IP to hostname.

Best Practices and Security Hardening (2026)

• Disable recursion on authoritative servers: recursion no;
• Restrict recursion on caching resolvers to trusted subnets only.
• Minimal responses: minimal-responses yes; reduces data exposure.
• DNSSEC validation for resolvers: dnssec-validation auto;
• Split-horizon (views) if serving internal and external clients differently.
• Rate limiting: use Response Rate Limiting (RRL) if available in your BIND build to mitigate amplification.
• Logging: enable query logging during troubleshooting, then disable to reduce noise and protect privacy.
• Keep BIND and OS patched. 2026 LTS releases ship BIND 9.18/9.20 branches—track security advisories.
• IPv6: Add AAAA records and ensure listen-on-v6 is enabled.
• Backups: version-control your zone files and document serial changes.

Troubleshooting Checklist

• Syntax errors: named-checkconf and named-checkzone should return OK.
• Firewall/NAT: Ensure UDP/TCP 53 is open and forwarded to the DNS host.
• SELinux/AppArmor: Adjust contexts/permissions if zones won’t load.
• Bind user permissions: zone files should be readable by bind/named.
• Wrong serial: After edits, bump the serial or secondaries won’t update.
• Glue records: For public authoritative servers, set glue at your registrar.
• Recursion leaks: Authoritative servers must not provide recursive answers.
• Reverse DNS: PTR records often need to be set with your IP provider if you don’t control the reverse zone.

Real-World Use Cases

• Small business: One authoritative VM for example.com, second slave in another AZ; recursion disabled, DNSSEC on domain.
• Enterprise LAN: Two caching resolvers with allow-recursion limited to RFC1918 subnets, forwarding to upstream secure resolvers.
• Developers: Split-horizon DNS via BIND views to expose internal *.dev.example.com only on VPN.

When to Use Managed DNS or a VPS

Running DNS in-house is powerful but requires monitoring, redundancy, and expertise. If you prefer reliability without the overhead, use managed DNS or deploy on a hardened VPS with automated snapshots. YouStable offers high-uptime VPS hosting ideal for BIND-based authoritative or caching resolvers, plus global DNS options for faster, redundant resolution. Choose the route that fits your team and SLA.

Quick Caching-Only Resolver (Optional)

Need a fast internal resolver? This minimal config turns BIND into a caching server for your LAN:

options {
    directory "/var/cache/bind";
    listen-on { 0.0.0.0; };
    listen-on-v6 { any; };
    recursion yes;
    allow-query { 10.0.0.0/8; 192.168.0.0/16; localhost; };
    allow-recursion { 10.0.0.0/8; 192.168.0.0/16; localhost; };
    forwarders { 1.1.1.1; 8.8.8.8; }; // optional for speed/failover
    dnssec-validation auto;
    minimal-responses yes;
};

Point client machines to this server’s IP as their DNS and verify with dig +stats to confirm cache hits.

FAQs: How to Configure DNS on Linux Server

Conclusion

Now you know how to configure DNS on a Linux server using BIND9—from installation and zone files to firewall rules, security, and testing. Keep configurations minimal, restrict recursion wisely, and monitor logs. When uptime is critical, consider redundant servers or a YouStable VPS and managed DNS to simplify operations while maintaining performance.