How do I fix 'named fails to start after an edit'?

Likely cause: Syntax error in named.conf or a zone file. Fix: Run named-checkconf and named-checkzone on every edited file before reloading.

How do I fix 'dig returns SERVFAIL'?

Likely cause: Zone failed to load (check the serial or a missing trailing dot). Fix: Inspect journalctl -u named for the load error; FQDNs in zone files need trailing dots.

How do I fix 'dig returns NXDOMAIN for a known name'?

Likely cause: Querying the wrong server or the record is in the wrong zone. Fix: Query with @server explicitly and confirm the name falls inside a configured zone.

How do I fix 'Reverse lookup returns nothing'?

Likely cause: Missing or misnamed reverse zone (wrong in-addr.arpa octet order). Fix: Build the reverse zone name by reversing the network octets.

How do I fix 'Changes do not appear'?

Likely cause: The zone was not reloaded, or a cached answer is being served. Fix: Run rndc reload, then query with +norecurse and check the TTL.

DNS Server Configuration: Networking Lab

I configured BIND9 as an authoritative server with forward and reverse zones for a local domain, including A, PTR, MX, and CNAME records. The deployment delivered internal name resolution validated end-to-end with dig against the server directly.

Objective & Context

DNS underpins almost every service interaction. This lab builds authoritative forward and reverse zones so internal hosts resolve by name and reverse lookups support logging and mail, complementing the DHCP and static-config labs.

Learning Objectives

Author forward and reverse zone files with SOA, NS, A, PTR, MX, and CNAME records.
Validate every zone with named-checkzone before reloading.
Reload zones safely with rndc without restarting the daemon.
Query the server directly with dig and interpret the answer section.
Explain when reverse (PTR) lookups matter: logging, mail, and access control.

Environment & Prerequisites

Prerequisites

Linux server with BIND9 (named) installed.
A local domain (lab.tyfsadik.org) and subnet for the reverse zone.
dig and named-checkzone for validation.
Linux server with BIND9 installed: sudo apt install -y bind9 bind9utils.
A local domain to serve authoritatively (this lab uses lab.tyfsadik.org) and a subnet for the reverse zone.
dig and named-checkzone for validation (both ship with bind9utils).
Root or sudo access to edit zone files and reload named.
Basic understanding of record types (A, PTR, MX, CNAME, NS, SOA).

flowchart LR Q[dig host.lab] --> N[BIND9 named] N --> F[(Forward zone A/MX/CNAME)] N --> R[(Reverse zone PTR)] F --> A[Answer] R --> A

Step-by-Step Execution

1. Define a forward zone record set

File content (place at /etc/bind/db.lab):

$TTL 3600
@   IN SOA ns1.lab.tyfsadik.org. admin.lab.tyfsadik.org. (2026092901 3600 600 86400 3600)
@   IN NS  ns1
ns1 IN A   192.168.20.2
nas IN A   192.168.20.10

What this teaches: a zone file is the authoritative source of truth for a domain, and the SOA serial tracks its revisions.

File content (add to /etc/bind/named.conf.local so named loads the zones):

zone "lab.tyfsadik.org" {
    type primary;
    file "/etc/bind/db.lab";
};
zone "20.168.192.in-addr.arpa" {
    type primary;
    file "/etc/bind/db.192.168.20";
};

Without the zone declaration in named.conf.local, named never loads the file: validation passes but queries still return SERVFAIL. The reverse zone name is the network octets reversed with .in-addr.arpa appended (192.168.20.0/24 becomes 20.168.192.in-addr.arpa).

2. Validate zones before reload [ROOT REQUIRED]

named-checkzone lab.tyfsadik.org /etc/bind/db.lab && rndc reload

Expected output:

zone lab.tyfsadik.org/IN: loaded serial 2026092901
OK
(nothing on success from rndc reload; confirm with: rndc status)

What this teaches: checking syntax before reload keeps one typo from taking down all resolution.

File content (place at /etc/bind/db.192.168.20):

$TTL 3600
@   IN SOA ns1.lab.tyfsadik.org. admin.lab.tyfsadik.org. (2026092901 3600 600 86400 3600)
@   IN NS  ns1.lab.tyfsadik.org.
2   IN PTR ns1.lab.tyfsadik.org.
10  IN PTR nas.lab.tyfsadik.org.

PTR records map the last octet back to a hostname. Validate with: named-checkzone 20.168.192.in-addr.arpa /etc/bind/db.192.168.20, then test with dig @192.168.20.2 -x 192.168.20.10.

3. Query the server directly

dig @192.168.20.2 nas.lab.tyfsadik.org +short

Expected output:

192.168.20.10

What this teaches: querying the server directly with @ bypasses the resolver chain and tests exactly what you configured.

How It Works

Authoritative DNS means this server is the final authority for its zones: when asked for a name in lab.tyfsadik.org, it answers from its own zone files instead of recursing. Forward zones map names to addresses (A records); reverse zones map addresses back to names (PTR records) under in-addr.arpa. Both directions are needed for complete service behavior.

Zone transfers and caching revolve around the SOA record. The serial number tells secondaries whether the zone changed, and the refresh/retry/expire timers control how they stay in sync. TTL values on individual records control how long resolvers cache answers, which is why lowering TTLs before a migration matters.

Validation tools exist because zone files are unforgiving. named-checkzone parses the file exactly as named would and reports the first error with a line number. rndc reload asks the running daemon to re-read zone files without dropping in-flight queries, which is the safe way to publish changes.

flowchart LR C["Client"] -->|"dig @server"| R["Resolver"] R -->|"authoritative query"| A["BIND9 named"] A --> Z["Zone files"] Z --> AN["Answer"] AN --> C

Validation & Testing

Resolve forward and reverse records and confirm the SOA serial incremented on each change. Pass criteria: correct A and PTR answers, authoritative AA flag set, and clean named-checkzone output.

Troubleshooting

Symptom	Likely cause	Fix
named fails to start after an edit	Syntax error in named.conf or a zone file	Run named-checkconf and named-checkzone on every edited file before reloading
dig returns SERVFAIL	Zone failed to load (check the serial or a missing trailing dot)	Inspect journalctl -u named for the load error; FQDNs in zone files need trailing dots
dig returns NXDOMAIN for a known name	Querying the wrong server or the record is in the wrong zone	Query with @server explicitly and confirm the name falls inside a configured zone
Reverse lookup returns nothing	Missing or misnamed reverse zone (wrong in-addr.arpa octet order)	Build the reverse zone name by reversing the network octets
Changes do not appear	The zone was not reloaded, or a cached answer is being served	Run rndc reload, then query with +norecurse and check the TTL

Advanced: Troubleshooting

SERVFAIL: a zone file syntax error; run named-checkzone and inspect /var/log/syslog.
Stale answers: bump the SOA serial; secondaries cache by serial.
Reverse lookup fails: confirm the in-addr.arpa zone and PTR records exist.

Key Results

Served authoritative forward and reverse resolution for the local domain.
Validated 100% of zones with named-checkzone before every reload.
Resolved A, PTR, MX, and CNAME records end-to-end via dig.
Standardized SOA serial discipline (date-based) for change tracking.

Key Takeaways

Validate with named-checkzone before every reload, without exception.
Trailing dots in zone files are load-bearing: omit one and the name gets the origin appended.
Query the authoritative server directly with dig @server to isolate problems.
Keep SOA serials monotonic so secondaries and tooling detect changes.

Practice Challenges

Challenge 1: Add an MX and SPF record

Goal: Publish a mail exchanger and an SPF TXT record for the lab domain, then verify both with dig.

Hint: MX points at a hostname, never a bare IP; the TXT record holds the v=spf1 policy.

Challenge 2: Slave the zone

Goal: Configure a second BIND9 server as a slave that transfers the zone via AXFR and answers queries identically.

Hint: Allow transfers with allow-transfer on the master and declare type slave on the second server.

Authoritative DNS Configuration with BIND9