Create Forward and Reverse DNS Zones in BIND (2026)

BIND, the venerable DNS server, is at its core a distributed database mapping names to IP addresses and vice-versa. Creating forward and reverse DNS zones isn’t about magic, it’s about populating this database correctly.

Let’s see BIND in action. Imagine we have a small network, example.com, with a web server www.example.com at 192.168.1.10 and a mail server mail.example.com at 192.168.1.20.

First, the forward zone. This is what most people think of as DNS: name to IP.

We’ll need to configure named.conf (or named.conf.local depending on your distro) to tell BIND about our zone.

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

Then, we create the zone file /etc/bind/db.example.com:

$TTL 604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.example.com.
ns1     IN      A       192.168.1.5    ; IP of our DNS server
www     IN      A       192.168.1.10
mail    IN      A       192.168.1.20

The SOA (Start of Authority) record is crucial. It identifies the primary name server for the zone and contains administrative information. The NS (Name Server) record points to the authoritative name server for the domain. A records map hostnames to IPv4 addresses. Notice the trailing dots on fully qualified domain names (FQDNs) like ns1.example.com. – they’re essential!

Now, the reverse zone. This maps IP addresses back to names, critical for many security protocols and troubleshooting. For our 192.168.1.0/24 network, the reverse zone is 1.168.192.in-addr.arpa.

We add this to named.conf:

zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.1";
};

And create the reverse zone file /etc/bind/db.192.168.1:

$TTL 604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.example.com.
5       IN      PTR     ns1.example.com.       ; 192.168.1.5
10      IN      PTR     www.example.com.       ; 192.168.1.10
20      IN      PTR     mail.example.com.      ; 192.168.1.20

Here, PTR (Pointer) records map the last octet of the IP address to the hostname. The @ symbol in the reverse zone file refers to 1.168.192.in-addr.arpa. itself.

After creating or modifying these files, you must reload BIND:

sudo systemctl reload named

Or, if you want to check the configuration syntax first:

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/db.example.com
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1

The most surprising true thing about DNS zone serial numbers is that they aren’t version numbers in the traditional sense; they are simply timestamps or arbitrary counters that a secondary DNS server uses to detect when the primary zone file has been updated. A secondary server polls the primary, and if the serial number it retrieves is higher than the one it has cached, it requests a zone transfer. If the serial number is lower, it assumes the primary has rolled back its zone data and will not request a transfer, potentially leading to stale DNS records.

This system effectively builds a distributed, fault-tolerant directory service. BIND reads these configuration files and zone files, then answers DNS queries based on the data it holds. You control the mapping of names to IPs and IPs to names directly within these text files.

The next concept you’ll encounter is configuring secondary DNS servers to receive zone transfers.