Cisco & Networking · Lesson 14
DHCP, DNS & NAT Concepts
Learn how clients receive addressing, resolve names, and cross translation boundaries without confusing service failures with VLAN, routing, ACL, or application problems.
Lesson Snapshot
Learning objectives
Troubleshoot the whole service chain
Explain the roles of DHCP, DNS, and NAT in an IPv4 network.
Trace how a client gets an address, resolves a name, and reaches a remote service.
Understand DHCP relay, DNS resolution, and common NAT terminology.
Inspect Cisco DHCP and NAT state safely before changing configuration.
Separate service failures from VLAN, routing, ACL, and application problems.
Verify required connectivity end to end before saving.
Core idea
Three services, three different jobs
DHCP gives configuration, DNS translates names, and NAT changes address representation. Test each service independently.
Competition warning
Do not fix the wrong layer
A raw-IP failure is not a DNS problem, and an empty NAT table is not proof of broken NAT if no matching traffic crossed the router.
Core concepts
Know what each service actually does
DHCP
Automatically supplies clients with IPv4 configuration such as address, mask, gateway, DNS server, and lease information.
DNS
Translates names into IP addresses so applications can locate services.
NAT
Changes IPv4 address representation as traffic crosses a translation boundary.
DHCP relay
Forwards DHCP messages between clients and a server on another subnet.
Resolver
The client-side component that asks a DNS server to resolve a name.
Translation table
Shows how NAT is currently mapping inside addresses to outside-facing representations.
End-to-end service chain
Follow the client from link to application
01
Join the VLAN
The endpoint first needs a working switchport and correct VLAN.
02
Receive addressing
DHCP or static configuration provides IP, mask, gateway, and DNS.
03
Resolve a name
If the application uses a hostname, the client asks its DNS resolver.
04
Route the packet
Remote traffic moves toward the default gateway and through the routing table.
05
Translate if required
At a NAT boundary, matching traffic may receive an inside-global representation.
06
Return successfully
Routing, ACLs, NAT state, and endpoint policy must allow the response back.
DHCP DORA
How a client receives a lease
Discover
Client searches for a DHCP server.
Offer
Server offers an address and lease options.
Request
Client requests the offered configuration.
Acknowledge
Server confirms the lease.
DHCP lease contents
An address alone is not enough
IPv4 address
Identifies the client on its subnet.
Subnet mask
Defines the local network boundary.
Default gateway
Provides the next hop for remote destinations.
DNS server
Tells the client where to send name queries.
Lease time
Defines how long the client may use the assignment before renewal.
Domain information
May provide a local suffix or related DNS information.
Cisco DHCP inspection
Inspect pools, bindings, conflicts, and relay
show ip dhcp pool
Review configured IOS DHCP pools and utilization.
show ip dhcp binding
Review active DHCP bindings.
show ip dhcp conflict
Review detected DHCP address conflicts where supported.
show running-config | section dhcp
Inspect DHCP pool and exclusion configuration.
show running-config interface <interface>
Check for ip helper-address on the client gateway.
show ip interface brief
Confirm the relay or gateway interface is operational.
IOS DHCP pool
Build a fictional Staff scope
Reserve infrastructure addresses
configure terminalip dhcp excluded-address 192.168.10.1 192.168.10.20Create the Staff pool
ip dhcp pool STAFFnetwork 192.168.10.0 255.255.255.0Set the gateway
default-router 192.168.10.1Set DNS
dns-server 192.168.30.53Verify
endshow ip dhcp poolshow ip dhcp bindingDHCP relay
Carry client broadcasts toward a remote server
DHCP begins with broadcast behavior
A new client may not know the server address yet.
Routers normally stop broadcasts
A server on another subnet therefore needs relay behavior.
ip helper-address provides relay
Cisco IOS can forward selected UDP broadcasts toward a configured server.
Relay belongs on the client gateway
Place the helper where client broadcasts arrive.
Routing still matters
The relay must reach the DHCP server and replies must return.
One missing helper can break one VLAN
Compare gateway interfaces when only one VLAN cannot obtain leases.
DHCP troubleshooting
Let the lease symptom narrow the problem
Client gets a 169.254.x.x address
Check VLAN, DHCP server, helper-address, pool availability, and server reachability.
VLAN 10 works but VLAN 20 has no leases
Compare VLAN 20 helper-address, scope, gateway interface, and routing.
Client receives an address from the wrong subnet
Check access VLAN, relay path, scopes, and any unintended DHCP source.
Client gets IP but no gateway
Inspect the DHCP default-router option.
Client gets IP and gateway but no DNS
Inspect the DHCP DNS-server option.
Pool is exhausted
Review exclusions, lease use, unexpected clients, and subnet sizing.
DNS concepts
Name resolution is a separate service layer
Resolver
Sends the client's DNS questions to a configured server.
Recursive server
Obtains the final answer for the client when configured to do so.
Authoritative server
Hosts official records for a DNS zone.
A record
Maps a hostname to an IPv4 address.
CNAME
Maps one DNS name to another DNS name.
PTR
Supports reverse lookup from IP address to name when configured.
DNS flow
From hostname to application connection
01
Application asks for a name
Example: portal.example.
02
Client checks local information
Cache or local host information may be checked first.
03
Resolver queries DNS
The request goes to the configured resolver.
04
DNS returns an answer
The client receives an address, another record, or an error.
05
Application uses the returned IP
Routing, ACLs, NAT, and service state now determine success.
DNS troubleshooting
Compare IP access with name-based access
Test a known IP directly
If IP works but the hostname fails, DNS becomes more likely.
Query the configured DNS server
Use nslookup or another available resolver tool.
Check the DHCP-provided DNS address
A correct lease can still contain the wrong resolver.
Check UDP and TCP 53 policy
DNS commonly uses UDP and can also require TCP.
Compare answer to expected server IP
Successful DNS can still return a stale or incorrect address.
Test by IP and by name
The difference separates name resolution from application reachability.
Cisco DNS awareness
Verify the resolver path before changing DNS
show running-config | include name-server
Review configured DNS resolver addresses on IOS where used.
show hosts
Review cached or configured hostname information where supported.
show running-config | include domain
Review domain-related device configuration.
ping <dns-server-ip>
Confirm IP reachability before blaming name resolution.
NAT terminology
Track address identity across the boundary
Inside local
The inside host address as it exists on the internal network.
Inside global
The address representing that inside host toward the outside.
Outside global
The outside host address as it exists in the global network.
Outside local
The outside host address as represented to the inside; often the same as outside global.
NAT types
Static, dynamic, and overload solve different needs
Static NAT
Fixed one-to-one mapping.
Common use
Useful when one internal host needs a predictable translated address.
Dynamic NAT
Chooses an address from a translation pool.
Common use
Useful when inside hosts temporarily consume available global addresses.
PAT / overload
Many inside hosts share one or a few global addresses by also tracking transport identifiers.
Common use
Common for outbound access from private networks.
Private IPv4 awareness
Common inside address space
10.0.0.0/8Private IPv4 range.
172.16.0.0/12Private IPv4 range from 172.16.0.0 through 172.31.255.255.
192.168.0.0/16Private IPv4 range common in labs and smaller networks.
Cisco NAT inspection
Read translation state before changing it
show ip nat translationsDisplay active translation entries.
show ip nat statisticsReview translation counts and inside/outside interface roles.
show running-config | include ip natLocate NAT-related configuration.
show running-config interface <interface>Verify ip nat inside or ip nat outside placement.
show access-listsReview ACLs used to classify translated traffic.
show ip routeVerify routing before concluding NAT is the problem.
PAT configuration pattern
Translate one fictional inside subnet outward
Classify Staff addresses
configure terminalaccess-list 1 permit 192.168.10.0 0.0.0.255Mark the inside
interface GigabitEthernet0/0ip nat insideMark the outside
interface GigabitEthernet0/1ip nat outsideEnable overload
exitip nat inside source list 1 interface GigabitEthernet0/1 overloadendVerify with authorized traffic
show ip nat translationsshow ip nat statisticsNAT ACLs classify traffic
An ACL referenced by NAT commonly identifies addresses to translate. That is different from applying an ACL to an interface with ip access-group.
NAT packet path
Translation still depends on routing
01
Inside host sends remote traffic
The packet leaves a private subnet toward the edge router.
02
Routing selects the outside path
The router still needs a valid route.
03
Traffic matches NAT classification
An ACL, route-map, or static mapping identifies eligible traffic.
04
Translation is created or used
Inside-local information is represented by an inside-global address.
05
Return traffic arrives
The edge router matches it to translation state.
06
Inside destination is restored
The packet is translated back and routed toward the internal host.
NAT troubleshooting
Translation evidence tells you where to look next
No translation appears
Check matching traffic, NAT ACL, inside/outside roles, routing, and interface state.
Translations appear but outside traffic fails
Check upstream route, return path, ACLs, and remote service state.
Only one subnet translates
Check whether the NAT classification intentionally includes the other subnet.
Static mapping exists but inbound service fails
Check outside reachability, ACLs, server service, mapping, and return route.
Wrong interface roles appear in statistics
Compare ip nat inside/outside to the actual topology.
Private host reaches internal but not outside networks
Check default route, NAT classification, outside interface, and upstream path.
Layered troubleshooting
Test in dependency order
1. Link
Are endpoint, switch, router, and server interfaces operational?
2. VLAN
Is the client in the correct VLAN and can it reach its gateway?
3. Addressing
Does the client have the correct IP, mask, gateway, and DNS server?
4. Routing
Can the network reach the DHCP/DNS server and outside path?
5. Policy
Do ACLs permit DHCP, DNS, and the required application?
6. NAT
If required, does traffic match translation and create the expected entry?
7. Application
Does the actual destination service respond?
Evidence-based reasoning
Fix the service that is actually failing
Client has no address in VLAN 20
Weak response
Changing NAT is unrelated.
Better reasoning
Start with VLAN 20, DHCP scope or relay, gateway interface, and server reachability.
Client can ping 192.168.30.10 but portal.example fails
Weak response
Routing is not necessarily broken.
Better reasoning
Check DNS configuration and whether the name resolves to the expected server.
NAT table is empty
Weak response
Do not rebuild NAT immediately.
Better reasoning
Generate authorized matching traffic and verify routing, interface roles, and classification first.
Only Staff gets DHCP leases
Weak response
Do not replace the whole DHCP server.
Better reasoning
Compare Student helper-address, pool, gateway, and routing.
DNS ACL permits only UDP 53
Weak response
Do not assume DNS can never need TCP.
Better reasoning
Verify whether TCP 53 is required in the environment.
PAT exists but outbound browsing fails
Weak response
Do not add duplicate overload rules.
Better reasoning
Check default route, NAT match criteria, outside path, ACLs, and upstream reachability.
Unsafe shortcuts
Changes that erase evidence or hide the real problem
Creating overlapping DHCP pools
Can produce duplicate or incorrect client addressing.
Adding helper-address to random interfaces
Can relay the wrong networks and hide the real gateway design.
Changing DNS because raw IP reachability fails
DNS is not required for direct IP connectivity.
Clearing NAT translations before documenting them
Removes useful evidence about matching traffic.
Marking the wrong NAT inside/outside interfaces
Can prevent or misdirect translation.
Using NAT to hide missing routes
Translation does not replace routing.
Verification
Prove each dependency separately
DHCP lease
Client receives the expected IP, mask, gateway, DNS server, and lease.
DHCP relay
Remote VLANs use the correct helper address and route to the server.
DNS
The configured resolver returns the expected address for the required hostname.
Routing
Required internal and outside destinations are reachable before NAT conclusions are made.
NAT roles
Interfaces are correctly marked inside and outside.
NAT match
Only intended traffic matches the translation rule.
Translations
Expected entries appear during authorized test traffic.
Application
The required service works by IP and by name where appropriate.
Defensive lab
Build and troubleshoot a fictional DHCP, DNS, and NAT path
Build a fictional network with Staff VLAN 10, Student VLAN 20, Server VLAN 30, a DHCP/DNS server, and an edge router.
Verify VLANs, inter-VLAN routing, and direct IP reachability before configuring relay or NAT.
Create Staff and Student DHCP scopes and configure the proper helpers on the client VLAN gateways.
Verify both clients receive the intended address, gateway, and DNS server.
Create a fictional DNS record for portal.example and verify resolution.
Configure PAT for Staff toward the simulated outside interface and verify a translation appears.
Introduce one fault such as a missing helper, wrong DNS option, wrong NAT role, or incomplete NAT ACL.
Use layered evidence to identify and correct only that fault, then retest each dependency.
Lesson checklist
Before moving on
I can explain DHCP, DNS, and NAT separately.
I understand DHCP Discover, Offer, Request, and Acknowledge.
I know what ip helper-address does.
I can explain why one VLAN can lose DHCP while another still works.
I can separate DNS failure from basic IP-connectivity failure.
I know DNS can use UDP and TCP port 53.
I understand static NAT, dynamic NAT, and PAT.
I can identify NAT inside and outside roles.
I know routing must work before NAT can create a successful end-to-end path.
I inspect NAT state before changing translation rules.
I do not use DNS or NAT changes to hide unrelated routing problems.
I verify the actual application after every dependency passes.
Reflection
Check your reasoning
Question 1
Why can one VLAN receive DHCP while another cannot?
Question 2
How does ip helper-address allow a remote DHCP server to serve another subnet?
Question 3
Why does access by IP but not by hostname point toward DNS?
Question 4
What is the difference between inside local and inside global?
Question 5
Why can a correct NAT rule still fail if routing is broken?
Question 6
What evidence should you collect before changing DHCP, DNS, or NAT?
Carry this forward
First prove the client has the right address, then prove routing, then prove name resolution, then inspect translation if the path crosses a NAT boundary. Dependency order prevents random changes.