Instruction 03-dns-dhcp-and-nat: Reading

DNS, DHCP, and NAT solve different problems even though a small home router may present them as one feature set. DHCP gives a client the information needed to participate on an IP network. A new client initially lacks a usable address and commonly begins with a broadcast DHCP Discover. A server responds with an Offer, the client sends a Request identifying the selected offer, and the server completes the exchange with an Acknowledgment. The resulting lease can include an address, prefix, default gateway, DNS server addresses, lease duration, and other options. A reservation is not the same thing as manually configuring an address: it remains server-managed but consistently maps a known client identifier to an intended address.

DNS answers naming questions. A client usually asks a recursive resolver for a record such as the A record for an IPv4 address or the AAAA record for an IPv6 address. If the answer is not cached, the resolver follows referrals through the DNS hierarchy until it reaches an authoritative source or another valid conclusion. Caching reduces delay and query volume, but it also means record changes are not instant. TTL values influence how long compliant caches may reuse an answer. A failed name lookup does not automatically mean that routing is broken; testing connectivity by address and then testing name resolution helps separate the two failure domains. Likewise, receiving a DNS server through DHCP does not prove that the DNS server is reachable or that it has the required records.

NAT rewrites packet addressing at a boundary. In a common IPv4 homelab, many private clients share one upstream address. Port Address Translation tracks combinations of protocol, source address, source port, destination address, and destination port, then assigns translated source ports so return traffic can be associated with the correct internal conversation. This state is normally created by outbound traffic and expires when it becomes idle or the protocol state ends. Inbound publishing requires an intentional static mapping or equivalent policy because an unsolicited packet has no existing translation entry that identifies an internal destination.

The normal dependency chain is: DHCP supplies an address, route, and resolver; DNS converts a service name into an address; routing sends packets toward the destination; and NAT may rewrite the flow at an address boundary. These services can also be deployed independently. Static clients do not require DHCP, direct address access does not require DNS, and globally routed networks may not require NAT. Troubleshooting should therefore test each layer independently rather than treating internet access as a single feature. Confirm the client configuration, test the local gateway, query the intended resolver, inspect the returned record, verify the route, and then inspect translation state where NAT is actually present. Finally, NAT must not be treated as a complete security control. Address rewriting can incidentally prevent some unsolicited traffic when no mapping exists, but access policy, service authentication, patching, segmentation, and logging remain separate responsibilities.