Authoritative DNS Configuration with BIND9
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.
Environment & 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.
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
$TTL 3600
@ IN SOA ns1.lab.tyfsadik.org. admin.lab.tyfsadik.org. (2026061701 3600 600 86400 3600)
@ IN NS ns1
ns1 IN A 192.168.20.2
nas IN A 192.168.20.10
2. Validate zones before reload [ROOT REQUIRED]
named-checkzone lab.tyfsadik.org /etc/bind/db.lab && rndc reload3. Query the server directly
dig @192.168.20.2 nas.lab.tyfsadik.org +short192.168.20.10
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.
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.