Instruction 02-local-dns-and-friendly-service-names: Reading

People remember names more reliably than addresses. A bookmark such as https://dashboard.home.arpa is easier to recognize and maintain than https://10.20.30.40. DNS supplies the translation, but it does not create application connectivity, configure a reverse proxy, or guarantee that a service is healthy. It only returns records in response to questions. A typical application asks the operating system's stub resolver for an address. The stub resolver sends the question to a configured recursive resolver, which may answer from cache, consult authoritative servers, or return an error. In a homelab, one resolver can also hold private records for internal services.

Local naming should use a deliberate namespace. RFC 8375 reserves home.arpa for residential home networks. The local suffix should generally be avoided for ordinary unicast DNS because it is conventionally associated with multicast DNS and may be handled differently by operating systems. Public domains that you do not control are also poor choices because future public records can conflict with private assumptions. Organizations that own a public domain may instead delegate or privately serve a subdomain, but that requires disciplined administration.

An A record maps a name to an IPv4 address, while an AAAA record maps a name to an IPv6 address. A CNAME points one name at another name and is useful for aliases, although clients must still resolve the target. DNS record design should represent stable service identities. For example, dashboard.home.arpa can remain constant while its address changes. Update the central record rather than editing bookmarks and application configurations across many clients.

Caching improves speed and reduces repeated work, but it also explains why DNS changes do not always appear immediately. A cached answer can remain in use until its TTL expires. Multiple clients can see different answers when they use different resolvers, retain different cache entries, or bypass the intended LAN resolver. Troubleshooting should therefore identify the exact resolver being queried, test the full name, inspect the response code, and compare direct queries with application behavior.

This lab runs dnsmasq only on 127.0.0.1:1053 and supplies an explicit configuration file. Port 1053 avoids the privileged standard DNS port and prevents the exercise from replacing the machine's configured resolver. The no-resolv and no-hosts settings make the source of the lab answers clear: only records written into the lab configuration are available. The local directive declares home.arpa as locally answered, so a missing name under that suffix should produce NXDOMAIN instead of being forwarded elsewhere. Because clients are not reconfigured, every test explicitly selects the server and port with dig.

A production design normally places a redundant or highly available resolver at stable LAN addresses, distributes those addresses to clients through network configuration, restricts who may query or administer the service, maintains both IPv4 and IPv6 records where appropriate, and monitors response health. Friendly names also belong in service documentation and certificates. If an HTTPS certificate does not contain the friendly name, DNS may resolve correctly while the browser still reports an identity error. Treat DNS as one layer in the service path, not as a substitute for routing, transport security, access control, or application monitoring.