Hands-on Lab·LPIC-2
A DNS zone, proved from a client
DNS is one of the largest areas on the 202 paper. This guide installs BIND, writes an authoritative zone with an A record, a CNAME and an NS record, validates it with named-checkzone before restarting anything, and then answers every question from the client - which is the only way to know the service is genuinely reachable.
202: DNS Guide 8 of 29 Intermediate
- OSUbuntu 26.04 LTS
- Kernel7.0.0-30-generic
- systemd259
- Block devicesone 50 GB disk
- TimeAbout 24 min
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPIC2-A01 | 192.168.0.78 | Ubuntu 26.04 LTS | Primary service host - BIND, Apache, Samba, Postfix. Topic 204 RAID runs on loop devices; this machine has no spare disk | 2 Core | 4 GB | 50 GB |
| LPIC2-C01 | 192.168.0.80 | Ubuntu 26.04 LTS | Client - resolves, mounts and connects, so every service is proven from a machine that is not running it | 2 Core | 4 GB | 50 GB |
This guide includes
Use this for one of the largest areas on the 202 paper. This matters because a query answered on the server proves nothing - only the query from another machine proves the zone is really being served.
- starting from a machine with no name server at all
- writing a zone file, with four record types and the SOA that heads it
- checking the configuration before restarting anything, and seeing what a broken zone looks like
- listening where the client can actually reach it
- running the query that proves nothing, and the one that proves everything
Before you start
- the-lab-a-service-needs-a-client
-
Start from nothing
-
A zone file, and the SOA record that heads it
-
Check the configuration before restarting anything
-
What a broken zone looks like
-
Listen where the client can reach it
-
The query that proves nothing, and the one that proves everything