DNS, DHCP, and NAT Services

Three Services, Three Jobs

A network can be cabled perfectly and still be unusable if its support services fail. DHCP, DNS, and NAT are distinct, and mixing them up slows every ticket. The one-line summary: DHCP gives you addressing, DNS resolves names to addresses, and NAT translates addresses between private and public.

DHCP — Dynamic Host Configuration Protocol

DHCP removes manual endpoint setup. A client and server complete a four-message exchange remembered as DORA:

The lease carries an IP address, subnet mask/prefix, default gateway, DNS server addresses, and a lease time. DHCP runs over UDP (server port 67, client port 68). In a small office the router or firewall is the DHCP server; in larger sites a dedicated server is used and routers run a DHCP relay (ip helper-address) to forward the broadcasts across VLANs. If DHCP fails entirely, the client self-assigns an APIPA address in 169.254.0.0/16 and loses its gateway.

DNS and NAT

DNS — Domain Name System

DNS maps human names like www.example.com to IP addresses. The client asks a configured resolver, which may recurse up to root, top-level-domain, and authoritative servers. DNS uses UDP port 53 for ordinary queries and TCP port 53 for large responses and zone transfers. DNS failure looks exactly like an Internet outage because names stop working even when raw IP connectivity is fine. The classic test: ping or browse a known IP versus the name. If the IP works but the name does not, DNS settings or DNS reachability are the suspect — not the link or the gateway.

NAT — Network Address Translation

NAT rewrites IP address information as traffic crosses a router or firewall. Internal networks use RFC 1918 private ranges, which are never routed on the public Internet:

PAT (Port Address Translation), also called NAT overload, lets many inside hosts share one public IP by tracking each conversation with a unique transport port number. NAT is not a firewall — it hides addresses but does not decide policy; firewall rules still permit or deny traffic.

A normal web visit ties it together

DHCP leases the client 192.168.10.25, gateway 192.168.10.1, DNS 192.168.10.10. DNS resolves the site to a public IP. The client sends to its gateway, which uses PAT to swap the private source for a public address. Replies return to the public address and the NAT table maps them back to the right inside host.

Isolating the failure

• No valid IP -> DHCP, VLAN, cabling, Wi-Fi, or relay.
• Valid IP, gateway pings, names fail -> DNS.
• Local and DNS fine, Internet fails for many users -> NAT, firewall, upstream routing, or ISP.

Common traps

• Calling everything 'the Internet is down' instead of separating what works from what fails.
• Believing NAT secures the network — it does not.
• Forgetting DHCP and DNS both ride UDP, so a UDP-blocking firewall can break both.

Leases, Record Types, and Translation Tables

Inside the DHCP lease

A lease is temporary. Roughly halfway through the lease time (the T1 timer, about 50%), the client tries to renew with the same server using a unicast Request; later (T2, about 87.5%) it broadcasts to any server. If renewal fails before the lease expires, the client gives up the address and falls back to APIPA. This is why a client that 'worked yesterday' can lose connectivity overnight when a DHCP server is down — the lease simply expired. A DHCP relay (the ip helper-address on a router) is essential in multi-VLAN networks because the client's Discover broadcast cannot cross a VLAN boundary on its own.

Common DNS record types

A CCST tech should recognize the everyday record types a resolver returns:

When nslookup name returns an address but the site still fails, DNS is fine and the fault is elsewhere; when nslookup times out or returns 'server failed', DNS is the problem.

Inside the NAT/PAT table

PAT keeps a translation table so replies find the right inside host. Each row maps an inside socket to an outside socket:

Because the port number distinguishes each conversation, dozens of inside hosts share one public address. If the table fills or an entry ages out mid-session, a long-idle connection can drop — another symptom worth recognizing.

Putting it together

The failure-isolation logic is always the same: confirm the client has a valid DHCP lease, that DNS resolves names, and that NAT plus routing carry packets outward. Test them in that order and a vague 'Internet is down' ticket resolves into a specific, fixable service.