Mastering BIND DNS Configuration: A Step-by-Step Guide to Setup, Troubleshooting, and Error Resolution

BIND (named) is the classic open-source DNS server. You run it when you want your own server to answer authoritatively for your domains, for example as ns1.yourbusiness.com on a VPS. This guide sets up an authoritative BIND server on a current Linux distribution, validates it, signs it with DNSSEC, and fixes the errors you are most likely to meet. It applies to a server you control, such as a VPS or dedicated server, not to shared hosting.

1. Do you need your own DNS server?

Running BIND makes you responsible for your domain's availability: if your DNS server is down, your website and email are unreachable, even if the web server is fine.

If you only need to change where your website or email points, see how to change your domain DNS settings instead.

2. Install BIND

CentOS has reached end of life. For a new server, use AlmaLinux or Rocky Linux 9, or Ubuntu 24.04 LTS or Debian 12.

AlmaLinux and Rocky Linux:

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

Main config: /etc/named.conf. Zone files: /var/named/.

Ubuntu and Debian:

sudo apt update
sudo apt install bind9 bind9-utils bind9-dnsutils
sudo systemctl enable --now named

Main config: /etc/bind/named.conf, which includes named.conf.options and named.conf.local. Keep zone files that BIND must write to, such as signed zones, in /var/lib/bind/.

Check the version with named -v. The examples below use features available in the BIND versions shipped with those distributions.

3. Configure the options for an authoritative server

An authoritative server answers only for its own zones. It must not resolve other domains for the whole internet: an open resolver is abused in DNS amplification attacks.

options {
    directory "/var/named";          // /var/cache/bind on Ubuntu and Debian
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    recursion no;                    // authoritative only
    allow-query { any; };            // anyone may ask about your zones
    allow-transfer { none; };        // no zone copies unless you allow them
    version "not disclosed";
    rate-limit { responses-per-second 10; };
};

• recursion no is the most important line. Older guides show recursion yes with allow-query { any; }, which creates an open resolver.
• rate-limit (response rate limiting) reduces the damage if someone uses your server to flood a victim with replies.
• allow-transfer stays none until you add a secondary server (section 6).

4. Create a zone

Declare the zone in /etc/named.conf (AlmaLinux and Rocky) or /etc/bind/named.conf.local (Ubuntu and Debian):

zone "example.com" {
    type primary;
    file "example.com.zone";
};

On Ubuntu and Debian, give the full path instead: file "/var/lib/bind/example.com.zone";. On very old BIND versions, primary is written master. Then create the zone file:

$TTL 3600
@       IN  SOA ns1.example.com. hostmaster.example.com. (
            2026092301 ; serial, YYYYMMDDnn
            3600       ; refresh
            900        ; retry
            1209600    ; expire
            300 )      ; negative-answer TTL
        IN  NS   ns1.example.com.
        IN  NS   ns2.example.com.
@       IN  A    192.0.2.10
ns1     IN  A    192.0.2.53
ns2     IN  A    198.51.100.53
www     IN  CNAME example.com.
@       IN  MX   10 mail.example.com.
mail    IN  A    192.0.2.25
@       IN  TXT  "v=spf1 mx -all"

Replace the documentation addresses with your own. Key points:

• The serial must go up every time you change the file, or secondary servers ignore the change. The date plus a two-digit counter is the usual pattern.
• The second field of the SOA line is an email address with the @ written as a dot.
• Every name ending in a dot is absolute. Leaving the final dot off ns1.example.com. turns it into ns1.example.com.example.com.

On AlmaLinux and Rocky Linux, set the owner so BIND can read the file: sudo chown root:named /var/named/example.com.zone, then sudo restorecon -v /var/named/example.com.zone for SELinux. On Ubuntu and Debian, run sudo chown bind:bind /var/lib/bind/example.com.zone.

5. Validate, reload and test

Never reload BIND without checking first:

Logs go to the system journal: sudo journalctl -u named -e.

6. Nameservers, glue records and a secondary server

A domain needs at least two nameservers, ideally on different servers and networks, so one failure does not take the domain offline.

• Secondary server. On the primary, allow transfers to the secondary's IP only, for example allow-transfer { 198.51.100.53; }; and also-notify { 198.51.100.53; }; in the zone. On the secondary, declare the zone as type secondary; with the primary's IP. For transfers over the internet, protect them with a TSIG key.
• Child nameservers. If your nameservers are named inside your own domain, such as ns1.example.com, the registry must store their IP addresses as glue records. See registering and managing child name servers.
• Delegation. Finally, set the domain's nameservers at your registrar to your two nameservers. See how do I change my nameservers.

Test the full path from the root down with dig +trace example.com.

7. Sign the zone with DNSSEC

DNSSEC signs your records so resolvers can detect forged answers. Current BIND versions manage keys automatically with a policy:

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

After a reload, BIND creates the keys and a signed copy of the zone. Get the DS record to give your registrar with:

dig @127.0.0.1 example.com DNSKEY | dnssec-dsfromkey -f - example.com

Add the DS record at your registrar only after the signed zone answers correctly from every nameserver. A wrong or stale DS record makes the whole domain fail for validating resolvers. Older guides use dnssec-keygen, dnssec-signzone and auto-dnssec maintain; the policy method replaces them.

8. Common errors and fixes

Even after a fix, resolvers may keep the old answer until its TTL expires. Lower the TTL a day before planned changes.

9. Where Domain India fits

On Domain India shared hosting (cPanel, DirectAdmin, Webuzo), you cannot run BIND or change server configuration. You manage records in your control panel instead; see managing DNS records.

To run your own DNS server, you need a server of your own. A Domain India VPS is self-managed with full root access, so BIND, its firewall and its updates are yours to run. Plan for two servers if the DNS must stay up.

The plan card shows the live Domain India list price, excluding 18% GST.

Ready to run your own DNS? Set up the servers with this guide, register your child name servers, then point the domain at them. If you only need to change a record, managing DNS records is the quicker route.