LFCE 38 🐧 BIND9 — Reverse Zones - KandZ

⏱️ Estimated read: 12 min | |

A reverse zone maps IP addresses back to hostnames. It is the mirror image of the forward zone: where the forward zone answers “what is the address for this name?” the reverse zone answers “what is the name for this address?” The data lives in a separate zone with a special name derived from the IP network, and the records are PTR rather than A or AAAA. Reverse zones are not optional decoration. Mail servers reject messages from IP addresses without matching PTR records, logging systems display hostnames instead of raw addresses, and security tools use reverse lookups to verify identity.

The previous chapter covered the forward zone file and its records. This chapter covers the reverse zone: the naming convention that turns an IP network into a zone name, the structure of the zone file, the PTR record syntax, and the dig -x command that tests the result. It also covers the IPv6 reverse zone, which uses a different naming scheme (ip6.arpa) and a nibble-reversed format.

Key point: The reverse zone name is the network portion of the IP address, reversed octet by octet, with .in-addr.arpa appended for IPv4. The 192.168.1.0/24 network becomes 1.168.192.in-addr.arpa. The PTR record’s owner name is only the host portion of the address—the last octet for a /24—because the zone name already identifies the network . The serial in the reverse zone’s SOA must be maintained independently from the forward zone’s serial.

Why reverse zones require a separate zone

The namespace problem.

DNS is a hierarchical namespace. Forward names like www.example.com live under the .com tree. IP addresses are not part of that tree. To map addresses to names, the DNS designers created a separate branch of the namespace: .arpa, and within it, in-addr.arpa for IPv4 and ip6.arpa for IPv6. The reverse zone for 192.168.1.0/24 is delegated as 1.168.192.in-addr.arpa . This is not a choice; it is the only way to express an IP-to-name mapping within the DNS protocol.

The delegation problem.

The in-addr.arpa tree is delegated by the same registries that allocate IP addresses. The Regional Internet Registry that allocates a block of addresses also delegates the corresponding reverse zone. An organization that receives 203.0.113.0/24 from its RIR can be delegated 113.0.203.in-addr.arpa, which gives it authority over the PTR records for that block . Without this delegation, the organization cannot publish authoritative reverse records, and lookups for its addresses will fail or return the ISP’s generic name.

The forward-reverse consistency problem.

A forward zone and a reverse zone are separate files with separate serial numbers. They can drift out of sync. A host that has an A record but no PTR record will resolve forward but not backward. A host with a PTR record that points to a name with no matching A record will produce a reverse lookup that does not verify forward. Mail servers and security tools check for this consistency; a mismatch is a red flag .

a. The reverse zone name and file structure

The zone name is the network address reversed and suffixed with .in-addr.arpa. For a /24, the first three octets are reversed: 192.168.1.0/24 becomes 1.168.192.in-addr.arpa. For a /16, the first two octets are reversed: 172.16.0.0/16 becomes 16.172.in-addr.arpa. For a /8, the first octet is reversed: 10.0.0.0/8 becomes 10.in-addr.arpa .

The zone file structure is the same as a forward zone, with SOA and NS records at the top and PTR records below.

; Reverse zone file for 192.168.1.0/24
$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2025010101 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300        ; negative TTL
)
@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

; PTR records: owner name is the last octet only
10  IN  PTR ns1.example.com.
11  IN  PTR ns2.example.com.
20  IN  PTR www.example.com.
25  IN  PTR mail.example.com.

The 10 in 10 IN PTR ns1.example.com. is relative to the zone origin. The full name is 10.1.168.192.in-addr.arpa., which is the reverse of 192.168.1.10. The trailing dot on the target name is mandatory; without it, BIND appends the reverse zone origin to the target, producing a name like ns1.example.com.1.168.192.in-addr.arpa. that does not exist .

b. Registering the reverse zone and testing

The reverse zone must be registered in named.conf.local (Debian) or named.conf (RHEL) before BIND will serve it.

# Debian: add to /etc/bind/named.conf.local
zone "1.168.192.in-addr.arpa" {
    type primary;
    file "/etc/bind/zones/1.168.192.in-addr.arpa.zone";
};

# RHEL: add to /etc/named.conf
zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/named/zones/1.168.192.in-addr.arpa.zone";
};

The type primary and type master are synonyms; BIND 9.16 and later accept both . After adding the zone, validate the configuration and the zone file, then reload.

# Validate the configuration
named-checkconf

# Validate the reverse zone file
named-checkzone 1.168.192.in-addr.arpa /etc/bind/zones/1.168.192.in-addr.arpa.zone
# Output: zone 1.168.192.in-addr.arpa/IN: loaded serial 2025010101
#         OK

# Reload BIND
rndc reload

The named-checkzone output confirms that the zone name matches the file’s contents. If the zone name passed to the command does not match the SOA record’s origin, the validation fails with a warning about the origin mismatch.

Testing uses dig -x, which converts the IP address to the reverse zone name and queries for a PTR record automatically .

# Reverse lookup for 192.168.1.20
dig @localhost -x 192.168.1.20
# Output: 20.1.168.192.in-addr.arpa. 86400 IN PTR www.example.com.

The -x flag is the standard way to test reverse resolution. Without it, a query to 20.1.168.192.in-addr.arpa with type PTR produces the same result, but the -x form is shorter and less error-prone.

c. IPv6 reverse zones and the nibble format

IPv6 reverse zones use ip6.arpa and a nibble-reversed format. Each hexadecimal digit of the address is reversed and separated by dots, and the zone name is the reversed network prefix. For the 2001:db8::/32 network, the zone name is 8.b.d.0.1.0.0.2.ip6.arpa .

; Reverse zone file for 2001:db8::/32
$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2025010101 3600 900 604800 300
)
@   IN  NS  ns1.example.com.

; PTR record for 2001:db8::20
; The full reverse name is 0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN  PTR www.example.com.

The owner name in the zone file contains only the portion of the nibble-reversed address that is not part of the zone name. The zone name 8.b.d.0.1.0.0.2.ip6.arpa covers the first 32 bits (the 2001:db8:: prefix). The remaining nibbles identify the host within that prefix. The full name is constructed by prepending the owner name to the zone origin.

The dig -x command works for IPv6 addresses as well.

# Reverse lookup for 2001:db8::20
dig @localhost -x 2001:db8::20

IPv6 reverse zones are more tedious to maintain manually because of the nibble reversal. In practice, they are often generated by tooling or updated dynamically, and the zone file is rarely edited by hand .

Complete Example Session

# ============================================
# PART 1: THE FORWARD ZONE (FOR REFERENCE)
# ============================================
# The forward zone has A records for the hosts
# whose reverse mappings will be created
cat /etc/bind/zones/example.com.zone
# Output includes:
# ns1 IN A 192.168.1.10
# www IN A 192.168.1.20

# ============================================
# PART 2: CREATE THE REVERSE ZONE FILE
# ============================================
sudo tee /etc/bind/zones/1.168.192.in-addr.arpa.zone > /dev/null <<'EOF'
$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2025010101 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        300        ; negative TTL
)
@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

; PTR records: owner is the last octet
10  IN  PTR ns1.example.com.
11  IN  PTR ns2.example.com.
20  IN  PTR www.example.com.
25  IN  PTR mail.example.com.
EOF

# ============================================
# PART 3: REGISTER THE ZONE
# ============================================
sudo tee -a /etc/bind/named.conf.local > /dev/null <<'EOF'
zone "1.168.192.in-addr.arpa" {
    type primary;
    file "/etc/bind/zones/1.168.192.in-addr.arpa.zone";
};
EOF

# ============================================
# PART 4: VALIDATE
# ============================================
sudo named-checkconf
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/zones/1.168.192.in-addr.arpa.zone
# Output: loaded serial 2025010101
#         OK

# ============================================
# PART 5: RELOAD
# ============================================
sudo rndc reload

# ============================================
# PART 6: TEST A PTR RECORD
# ============================================
dig @localhost -x 192.168.1.20
# Output: 20.1.168.192.in-addr.arpa. 86400 IN PTR www.example.com.

# ============================================
# PART 7: TEST A MISSING PTR
# ============================================
dig @localhost -x 192.168.1.99
# Output: status: NXDOMAIN
# The address has no PTR record in this zone

# ============================================
# PART 8: VERIFY FORWARD-REVERSE CONSISTENCY
# ============================================
# Forward: www -> 192.168.1.20
dig @localhost www.example.com A
# Reverse: 192.168.1.20 -> www.example.com
dig @localhost -x 192.168.1.20
# Both should return matching data

# ============================================
# PART 9: CREATE AN IPV6 REVERSE ZONE
# ============================================
sudo tee /etc/bind/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone > /dev/null <<'EOF'
$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2025010101 3600 900 604800 300
)
@   IN  NS  ns1.example.com.

0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN  PTR www.example.com.
EOF

# ============================================
# PART 10: VALIDATE AND TEST IPV6
# ============================================
sudo named-checkzone 8.b.d.0.1.0.0.2.ip6.arpa /etc/bind/zones/8.b.d.0.1.0.0.2.ip6.arpa.zone
sudo rndc reload
dig @localhost -x 2001:db8::20

The ten parts demonstrate the complete reverse zone workflow: creating the file, registering the zone, validating, reloading, testing a PTR record, testing a missing record, verifying forward-reverse consistency, and extending to IPv6. The critical verification is Part 8, where the forward and reverse lookups must agree.

Quick Reference

Reverse Zone Naming

Network	Reverse Zone Name
`192.168.1.0/24`	`1.168.192.in-addr.arpa`
`172.16.0.0/16`	`16.172.in-addr.arpa`
`10.0.0.0/8`	`10.in-addr.arpa`
`2001:db8::/32`	`8.b.d.0.1.0.0.2.ip6.arpa`

PTR Record Syntax

Network	Owner Name	Full Name
`/24`	`20`	`20.1.168.192.in-addr.arpa`
`/16`	`1.20`	`1.20.16.172.in-addr.arpa`
`/8`	`1.20.30`	`1.20.30.10.in-addr.arpa`

Commands

Command	Purpose
`named-checkzone <zone> <file>`	Validate reverse zone file
`rndc reload`	Reload configuration
`dig -x <ip>`	Reverse lookup for IPv4 or IPv6
`dig <name> A`	Forward lookup for comparison

Best Practices

✅ Do This:

# Reverse the network octets for the zone name
zone "1.168.192.in-addr.arpa" { ... };                      # ✅

# Use only the host portion as the owner name
20 IN PTR www.example.com.                                  # ✅

# End the target name with a dot
20 IN PTR www.example.com.                                  # ✅

# Validate before reloading
named-checkzone 1.168.192.in-addr.arpa /path/to/zone        # ✅

# Test with dig -x
dig @localhost -x 192.168.1.20                              # ✅

# Keep forward and reverse serials in sync conceptually
# Both must increase on change                              # ✅

❌ Don’t Do This:

# Use the forward zone name for a reverse zone
zone "example.com" { ... };    # Not a reverse zone         # ❌

# Use the full reversed address as the owner name in a /24
20.1.168.192 IN PTR www.example.com.    # Wrong; zone name already covers it # ❌

# Omit the trailing dot on the target
20 IN PTR www.example.com    # Becomes www.example.com.1.168.192.in-addr.arpa. # ❌

# Forget to register the zone in named.conf
# The file exists but BIND does not serve it                # ❌

# Skip validation
rndc reload    # A syntax error prevents the zone from loading # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Reverse lookup returns NXDOMAIN	Zone not registered or PTR missing	Add zone to `named.conf`; add PTR record
PTR returns wrong name	Missing trailing dot on target	Append `.` to the target FQDN
Zone fails to load	Owner name includes full reversed address	Use only the host portion
Forward and reverse disagree	PTR points to a name with no A record	Ensure PTR target has a matching A record
IPv6 reverse fails	Used `in-addr.arpa` instead of `ip6.arpa`	Use `ip6.arpa` and nibble-reversed format
Serial not incremented	Forgot to update SOA serial	Increment serial on every change

Real-World Examples

1. Reverse zone for /24

zone "1.168.192.in-addr.arpa" { type primary; file "/etc/bind/zones/1.168.192.in-addr.arpa.zone"; };

2. PTR record in /24

20 IN PTR www.example.com.

3. Reverse zone for /16

zone "16.172.in-addr.arpa" { type primary; file "/etc/bind/zones/16.172.in-addr.arpa.zone"; };

4. PTR record in /16

1.20 IN PTR www.example.com.

5. IPv6 reverse zone

zone "8.b.d.0.1.0.0.2.ip6.arpa" { type primary; file "/etc/bind/zones/ip6.zone"; };

6. IPv6 PTR record

0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.example.com.

7. Validate reverse zone

named-checkzone 1.168.192.in-addr.arpa /etc/bind/zones/1.168.192.in-addr.arpa.zone

8. Reverse lookup

dig @localhost -x 192.168.1.20

9. Reverse lookup for IPv6

dig @localhost -x 2001:db8::20

10. Verify forward-reverse match

dig @localhost www.example.com A; dig @localhost -x 192.168.1.20

Visual

Reverse Zone Naming

┌──────────────────────────────────────────────────────────────┐
│  THE ZONE NAME IS THE NETWORK REVERSED                       │
│                                                              │
│  Network: 192.168.1.0/24                                     │
│  Octets:  192 . 168 . 1 . 0                                  │
│  Reversed: 1 . 168 . 192                                     │
│  Zone:    1.168.192.in-addr.arpa                             │
│                                                              │
│  Network: 172.16.0.0/16                                      │
│  Octets:  172 . 16 . 0 . 0                                   │
│  Reversed: 16 . 172                                          │
│  Zone:    16.172.in-addr.arpa                                │
│                                                              │
│  PTR owner names contain only the host portion:              │
│  For 192.168.1.20 → owner is "20"                            │
│  Full name: 20.1.168.192.in-addr.arpa                        │
└──────────────────────────────────────────────────────────────┘

PTR Record Structure

┌──────────────────────────────────────────────────────────────┐
│  PTR RECORD IN A /24 REVERSE ZONE                            │
│                                                              │
│  Zone: 1.168.192.in-addr.arpa                                │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ 20  IN  PTR  www.example.com.                          │  │
│  │ │         │                                            │  │
│  │ │         └── Target name (trailing dot required)      │  │
│  │ │                                                      │  │
│  │ └── Owner name (last octet only)                       │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Full reverse name: 20.1.168.192.in-addr.arpa.               │
│  Maps back to 192.168.1.20.                                  │
└──────────────────────────────────────────────────────────────┘

Forward-Reverse Consistency

┌──────────────────────────────────────────────────────────────┐
│  BOTH ZONES MUST AGREE                                       │
│                                                              │
│  Forward zone (example.com):                                 │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ www  IN  A  192.168.1.20                               │  │
│  └────────────────────────────────────────────────────────┘  │
│                           │                                  │
│                           ▼                                  │
│  Reverse zone (1.168.192.in-addr.arpa):                      │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ 20  IN  PTR  www.example.com.                          │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Forward lookup: www.example.com → 192.168.1.20              │
│  Reverse lookup: 192.168.1.20 → www.example.com              │
│                                                              │
│  If either side is missing, the mapping is incomplete.       │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
IPv4 reverse zone	`<reversed-network>.in-addr.arpa`
IPv6 reverse zone	`<nibble-reversed-prefix>.ip6.arpa`
Record type	`PTR`
Owner name	Host portion only (last octet for /24)
Target name	Must end with a dot
Zone registration	`named.conf.local` or `named.conf`
Validation	`named-checkzone <zone> <file>`
Testing	`dig -x <ip>`
Consistency check	Forward `A` and reverse `PTR` must match

Key takeaways:

The reverse zone name is the network reversed. 192.168.1.0/24 becomes 1.168.192.in-addr.arpa. The PTR record’s owner name is only the host portion, because the zone name already identifies the network .
The target name must end with a dot. Without it, BIND appends the reverse zone origin to the target, producing a name like www.example.com.1.168.192.in-addr.arpa. that does not exist.
The reverse zone must be registered separately. Creating the file is not enough. The zone statement in named.conf.local or named.conf tells BIND to serve it .
dig -x is the test command. It converts the IP address to the reverse zone name and queries for a PTR record. It works for both IPv4 and IPv6 .
Forward and reverse must agree. A PTR record that points to a name with no matching A record is a configuration error. Mail servers and security tools check for this consistency .
IPv6 reverse zones use ip6.arpa and nibble reversal. Each hexadecimal digit is reversed and separated by dots. The format is more tedious but follows the same principle as IPv4 .

Remember: A reverse zone is the address-to-name mirror of the forward zone. The zone name is the network reversed, the record is PTR, and the owner name is the host portion. Register the zone, validate it with named-checkzone, and test it with dig -x. The forward and reverse zones are separate files with separate serials, but they describe the same hosts from two directions. A complete DNS configuration includes both.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!