01 / THE ROLE
In this lab.
BIND9 supplies internal authoritative DNS. The zone and record configuration is maintained as code, with a DNS update workflow using OpenTofu. Keeping names in configuration makes additions and corrections reviewable instead of relying only on manual changes.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Name query
- STEP 02Authoritative zone
- STEP 03Matching record
- STEP 04DNS answer
03 / How it works
How it works.
An authoritative server answers for zones it manages. A new application may need both a DNS record and a reverse-proxy route, and those changes serve different purposes: DNS identifies a destination, while the proxy decides how an HTTP request is handled. This guide does not assume a particular upstream chain between the lab’s DNS tools.
04 / Persistent data & recovery
Persistent data & recovery.
Zone intent belongs in version control; runtime zone data and the administrative material needed to apply changes have their own recovery requirements. DNS data and access credentials should be restored through the private operational procedure, not a public zone export.
05 / How to check it
How to check it.
Check the expected answer and record type, authoritative behaviour and resolution from the relevant client environment. A server answering one query does not prove updates are working. Existing answers may also survive in caches after configuration changes.
06 / Decisions & limits
Decisions & limits.
DNS is a small service with a large dependency footprint. Incorrect or stale names can look like an application fault, so name resolution is an early troubleshooting step.