DNS administration requires you to reason about two different jobs: answering authoritatively for names you own and resolving everything else through an upstream service and local cache. This hands-on course uses BIND9 to make both paths visible and testable from a Linux terminal.
You will install and run named, inspect port 53 over UDP and TCP, build master zone files, add records, update the SOA serial, and validate before reload. The final challenge creates an internal office.lan namespace for three devices while forwarding external queries to Google Public DNS.
What You Will Learn
- Install BIND9 and its utilities, start
named, and verify UDP/TCP port 53 - Organize global options, local zone declarations, and zone data files
- Configure a forwarder and compare cold and cached query times
- Build a master zone with valid SOA, NS, and A records and trailing dots
- Add A and CNAME records, increment the serial, and reload with
rndc - Validate configuration and zone data with
named-checkconfandnamed-checkzone - Diagnose resolution with targeted
dig, reverse lookup,+trace, and BIND log searches
Who This Course Is For
This intermediate course is for Linux administrators, DevOps and networking learners, support engineers, and developers who need to operate a small internal DNS service. It is useful if you understand hostnames and IP addresses but have not yet created an authoritative zone, configured forwarding, or interpreted DNS diagnostics.
Prerequisites: Basic Linux terminal, networking, package, process, file-editing, and sudo skills. Familiarity with IP addresses and domain-name structure is helpful.
Learning environment: A Debian/Ubuntu-style LabEx Linux terminal with BIND9, dig, prepared configuration templates and logs, and network access for forwarded public DNS queries.
Frequently Asked Questions
Is this an authoritative DNS course or a caching-resolver course?
It covers both roles on one BIND instance. The server answers authoritatively for locally defined zones such as lab.local and office.lan, while unknown public names are forwarded to 8.8.8.8 and their replies are cached until TTL expiry.
Will this configure the machine or other clients to use the new DNS server automatically?
No. The exercises query the server explicitly with commands such as dig @127.0.0.1 printer.office.lan. They do not edit /etc/resolv.conf, configure DHCP-provided DNS settings, or enroll other hosts as clients.
Which DNS records and production features are included?
You create SOA, NS, A, and CNAME records and inspect an existing PTR through reverse lookup. The course does not create reverse zones, MX, AAAA, or TXT records, nor does it configure DNSSEC, secondary servers, dynamic updates, access-control lists, or zone transfers.
