Infrastructure Services (DHCP & DNS)

Opening Framing: The Two Services Every Network Depends On

Every previous week has assumed that hosts already have IP addresses and that you already know the destination's IP. In practice, neither is true. A laptop that joins a corporate Wi-Fi network does not have an address until something gives it one. A user who types www.example.com into a browser does not know the server's IP until something resolves the name. Those two "somethings" are DHCP and DNS — the infrastructure services that make every other network function usable.

DHCP (Dynamic Host Configuration Protocol) automates IP address assignment. Without it, every device on every network would need manual configuration — an operational impossibility on campuses with thousands of devices, guest networks with transient clients, and cloud environments that scale on demand. DNS (Domain Name System) translates human-readable hostnames into IP addresses. Without it, users would need to memorize addresses, and every change in server hosting would require manual updates across every client.

These are not luxury services. If DHCP fails, new devices cannot join the network. If DNS fails, the internet effectively stops working for most users even though the underlying IP connectivity is still intact. Understanding how both protocols work, how to configure them, and how to troubleshoot them is essential for every networking role.

Learning Outcomes

• LO1: Describe the four-step DHCP DORA process and explain what each message contains, who sends it, and what addressing it uses.
• LO2: Configure a basic DHCP server and a DHCP relay agent on Cisco IOS, and verify that clients receive correct addressing.
• LO3: Explain the DNS hierarchy from root servers through TLD and authoritative servers, and distinguish recursive from iterative resolution.
• LO4: Use nslookup, dig, and ipconfig /displaydns to query DNS records and diagnose resolution failures.
• LO5: Troubleshoot common DHCP and DNS failures including scope exhaustion, relay misconfiguration, stale cache, and wrong DNS server settings.

Key insight: DHCP and DNS are the first things to break and the last things students think to check. Most "the internet is down" reports are actually DHCP or DNS failures.

1) Why Manual Configuration Does Not Scale

In Weeks 4-6, you manually assigned IP addresses, subnet masks, and default gateways to hosts. That works in a lab with five devices. It does not work in a hospital with 3,000 workstations, a university with 10,000 students connecting personal laptops, or a cloud environment spinning up dozens of virtual machines per minute. Manual configuration creates three operational problems:

• Human error: Typos in IP addresses or subnet masks cause connectivity failures that are difficult to trace. A single wrong digit can place a host on the wrong subnet or create a duplicate address conflict.
• Address tracking: Without automation, someone must maintain a spreadsheet or database of which address is assigned to which device. When devices leave the network, addresses must be manually reclaimed.
• Mobility: When a laptop moves from one building to another (different subnet), its static address is wrong. The user must either reconfigure manually or call support.

DHCP eliminates all three problems. It assigns addresses from a managed pool, tracks active leases, and reclaims addresses when devices leave. DNS solves a parallel problem: without name resolution, every application, service reference, and user bookmark would need to use raw IP addresses — and those addresses can change whenever infrastructure moves.

2) DHCP: The DORA Process Step by Step

DHCP uses a four-message exchange called DORA: Discover, Offer, Request, Acknowledge. This exchange happens every time a client needs an IP address — at boot, when a lease expires, or when a device joins a new network. All four messages are carried over UDP (client port 68, server port 67).

Step 1: Discover

The client has no IP address yet, so it sends a DHCP Discover as a broadcast. The source IP is 0.0.0.0 (the client has no address to use), and the destination IP is 255.255.255.255 (broadcast to every device on the local subnet). The message contains the client's MAC address so the server can identify which device is asking.

Step 2: Offer

Every DHCP server that receives the Discover responds with a DHCP Offer. The Offer contains a proposed IP address, subnet mask, default gateway, DNS server addresses, and a lease duration. The Offer is typically sent as a broadcast (because the client does not yet have an IP to receive unicast traffic), though some implementations use unicast.

Step 3: Request

The client selects one Offer (usually the first one received) and broadcasts a DHCP Request announcing which server's offer it has accepted. This broadcast serves two purposes: it tells the chosen server to finalize the lease, and it tells all other DHCP servers to withdraw their offers.

Step 4: Acknowledge

The selected server sends a DHCP Acknowledge (ACK) confirming the lease. The client now applies the IP address, subnet mask, default gateway, and DNS server to its network interface. The lease timer begins. When the lease reaches 50% of its duration, the client sends a unicast DHCP Request directly to the server to renew the lease. If renewal fails, it tries again at 87.5%. If still unsuccessful, the client restarts the DORA process.

DHCP DORA exchange

Client (no IP)                              DHCP Server (10.1.1.100)
      |                                            |
      |--- DHCP Discover (broadcast) ------------->|
      |    Src IP: 0.0.0.0                         |
      |    Dst IP: 255.255.255.255                 |
      |    Src MAC: client's MAC                   |
      |    UDP: src 68, dst 67                     |
      |                                            |
      |<-- DHCP Offer (broadcast) -----------------|
      |    Offered IP: 10.1.1.50                   |
      |    Mask: 255.255.255.0                     |
      |    Gateway: 10.1.1.1                       |
      |    DNS: 10.1.1.100                         |
      |    Lease: 8 hours                          |
      |                                            |
      |--- DHCP Request (broadcast) -------------->|
      |    "I accept 10.1.1.50 from 10.1.1.100"   |
      |                                            |
      |<-- DHCP ACK (broadcast or unicast) --------|
      |    Confirmed: 10.1.1.50 for 8 hours        |
      |                                            |
Client configures interface with 10.1.1.50/24
Gateway: 10.1.1.1 | DNS: 10.1.1.100

3) DNS: The Hierarchy That Resolves Names to Addresses

DNS is a distributed, hierarchical database that maps domain names to IP addresses (and other record types). It is the reason you can type www.google.com instead of 142.250.80.4. DNS is also far more than a phone book — it controls mail routing (MX records), service discovery (SRV records), domain verification (TXT records), and security policy (CAA, DNSKEY, DS records).

The DNS Hierarchy

DNS hierarchy (example: resolving www.example.com)

                    .  (root)
                    |
          +---------+---------+
          |         |         |
        .com      .org      .net     (TLD — Top-Level Domain servers)
          |
      example.com              (Authoritative name server for example.com)
          |
     www.example.com           (A record: 93.184.216.34)

The hierarchy has four levels of DNS servers, each responsible for a different part of the resolution:

Recursive vs. Iterative Resolution

When a client (your laptop) needs to resolve a name, it sends a recursive query to its configured DNS resolver. "Recursive" means the client expects a complete answer — the resolver must do all the work. The resolver then performs iterative queries to the hierarchy: it asks the root server, which refers it to the TLD server, which refers it to the authoritative server, which returns the answer. The resolver caches the result and returns it to the client.

Full DNS resolution process (www.example.com)

1. Client sends recursive query to resolver (e.g., 8.8.8.8):
   "What is the IP for www.example.com?"

2. Resolver checks its cache. Cache miss → starts iterative queries.

3. Resolver asks root server: "Where is .com?"
   Root replies: "Ask the .com TLD server at 192.5.6.30"

4. Resolver asks .com TLD: "Where is example.com?"
   TLD replies: "Ask the authoritative server at 93.184.216.34"

5. Resolver asks authoritative server: "What is www.example.com?"
   Authoritative replies: "A record: 93.184.216.34, TTL: 3600"

6. Resolver caches the answer for 3600 seconds (1 hour).
   Resolver returns 93.184.216.34 to the client.

7. Client connects to 93.184.216.34.

Subsequent queries for www.example.com within the TTL
are answered from cache — no hierarchy walk needed.

Common DNS Record Types

4) DHCP Relay: Crossing Subnet Boundaries

DHCP Discover messages are broadcasts. Broadcasts do not cross routers. In any network with multiple subnets and a centralized DHCP server, the router between the client's subnet and the server's subnet must act as a DHCP relay agent. The relay intercepts the client's broadcast, converts it into a unicast packet aimed at the DHCP server, and forwards it across the routed network.

How DHCP Relay Works

1. Client broadcasts DHCP Discover on its local subnet.
2. The router's interface on that subnet has ip helper-address configured, pointing to the DHCP server's IP.
3. The router receives the broadcast, inserts the GIADDR (Gateway IP Address) field with the router interface's IP. This tells the DHCP server which subnet the client is on.
4. The router unicasts the Discover to the DHCP server.
5. The DHCP server reads the GIADDR, selects an address from the correct scope for that subnet, and sends the Offer back to the relay's IP.
6. The relay forwards the Offer to the client on the local subnet (broadcast or unicast).
7. Request and ACK follow the same relay path.

DHCP relay topology

[Client] --broadcast--> [Router g0/0] --unicast--> [DHCP Server 10.1.1.100]
  VLAN 20                ip helper-address             Has scopes for:
  10.20.0.0/24           10.1.1.100                    - 10.1.1.0/24 (local)
                         GIADDR = 10.20.0.1            - 10.20.0.0/24 (remote via relay)

Router configuration:
  interface g0/0
   ip address 10.20.0.1 255.255.255.0
   ip helper-address 10.1.1.100

The DHCP server sees GIADDR = 10.20.0.1 and knows to offer
an address from the 10.20.0.0/24 scope.

5) Configuration: DHCP Server and DNS Relay in Cisco IOS

Cisco routers can serve as both DHCP servers (for smaller networks) and DHCP relay agents (in enterprise deployments where a dedicated server handles the load). Below is a practical configuration for both roles.

Configuring a DHCP Server on a Cisco Router

! Create a DHCP pool
Router(config)# ip dhcp pool OFFICE_LAN
Router(dhcp-config)# network 10.1.1.0 255.255.255.0
Router(dhcp-config)# default-router 10.1.1.1
Router(dhcp-config)# dns-server 8.8.8.8 8.8.4.4
Router(dhcp-config)# lease 0 8 0
Router(dhcp-config)# exit

! Exclude addresses that should not be assigned dynamically
Router(config)# ip dhcp excluded-address 10.1.1.1 10.1.1.10

Explanation:
- network: defines the subnet and scope
- default-router: the gateway sent to clients (DHCP Option 3)
- dns-server: DNS servers sent to clients (DHCP Option 6)
- lease 0 8 0: 0 days, 8 hours, 0 minutes
- excluded-address: reserves 10.1.1.1-10 for static devices (router, servers, printers)

Configuring a DHCP Relay Agent

! On the router interface facing the remote VLAN
Router(config)# interface g0/1
Router(config-if)# ip address 10.20.0.1 255.255.255.0
Router(config-if)# ip helper-address 10.1.1.100
Router(config-if)# no shutdown

Note: ip helper-address also forwards other UDP broadcast services
by default (TFTP, DNS, TACACS, NetBIOS). You can restrict this
with global configuration if needed.

Verification Commands

Cisco IOS DHCP verification:
show ip dhcp binding         Active leases (IP, MAC, lease expiry)
show ip dhcp pool            Pool statistics (total, leased, available)
show ip dhcp server statistics  Counters for DORA messages
debug ip dhcp server events  Real-time DHCP message log (use with caution)

Client verification:
Windows:
  ipconfig /all              Shows IP, mask, gateway, DNS, DHCP server, lease times
  ipconfig /release          Releases current DHCP lease
  ipconfig /renew            Requests a new lease

Linux:
  ip addr                    Shows current IP configuration
  dhclient -r                Release lease
  dhclient                   Request new lease
  cat /var/lib/dhcp/dhclient.leases   View lease details

DNS Verification Commands

Windows:
nslookup www.example.com           Query default DNS server
nslookup www.example.com 8.8.8.8   Query a specific DNS server
ipconfig /displaydns               Show local DNS cache
ipconfig /flushdns                 Clear local DNS cache

Linux / macOS:
dig www.example.com                Full DNS query with answer and authority sections
dig www.example.com +short         Just the IP answer
dig @8.8.8.8 www.example.com      Query a specific server
dig -x 93.184.216.34               Reverse DNS lookup (PTR record)
host www.example.com               Simple forward lookup
nslookup www.example.com           Interactive DNS query

Example: dig output

$ dig www.example.com

;; ANSWER SECTION:
www.example.com.    3600    IN    A    93.184.216.34

;; AUTHORITY SECTION:
example.com.        86400   IN    NS   a.iana-servers.net.
example.com.        86400   IN    NS   b.iana-servers.net.

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Interpretation:
- A record: www.example.com resolves to 93.184.216.34
- TTL: 3600 seconds (1 hour) — cached answer valid for this long
- Authority: iana-servers.net are the authoritative name servers
- Query time: 24 ms — if this were a cache hit, it would be < 1 ms
- SERVER: the resolver that answered the query

6) Troubleshooting and Failure Modes

DHCP and DNS failures are among the most reported issues in enterprise networks. They are often misdiagnosed as "the internet is down" or "the network is broken" when in reality the IP connectivity is intact and only the service layer has failed. Systematic diagnosis separates infrastructure service failures from actual connectivity failures.

DHCP Troubleshooting Workflow

1. Check the client: does it have an APIPA address (169.254.x.x) or no address at all? This indicates DHCP failure.
2. Release and renew: ipconfig /release then ipconfig /renew. Watch Wireshark for DORA messages.
3. If no Offer is received: check the DHCP server status, verify ip helper-address, and confirm no ACL blocks UDP 67/68.
4. If an Offer is received but with wrong parameters: inspect the DHCP pool configuration on the server.
5. If the scope is full: show ip dhcp pool to check utilization; consider shorter lease times or larger scopes.

DNS Troubleshooting Workflow

1. Can you ping by IP? If yes, the network works — the problem is DNS.
2. Run nslookup www.example.com. Does it return an answer? If not, the DNS server may be down or unreachable.
3. Try an alternate DNS server: nslookup www.example.com 8.8.8.8. If this works, the configured DNS server is the problem.
4. Flush the DNS cache: ipconfig /flushdns. Re-query. If the problem was a stale cache entry, this resolves it.
5. If the authoritative answer is wrong, the DNS zone file needs to be updated on the authoritative server.

Real-World Design Context: DHCP and DNS at Scale

DHCP and DNS are not just helper protocols. They are critical infrastructure services that require careful design, redundancy, and monitoring in any production environment.

• DHCP redundancy: Enterprise networks deploy DHCP in failover pairs (split-scope or hot-standby) so that a single server failure does not prevent new devices from joining. Windows DHCP failover and ISC DHCP failover are common implementations. In cloud environments, the infrastructure provider handles DHCP (e.g., AWS VPC DHCP options sets).
• DNS redundancy: Every domain should have at least two authoritative name servers on separate networks. Recursive resolvers should also be redundant — clients typically receive two DNS server addresses via DHCP.
• Security: DHCP snooping. Managed switches can be configured to trust DHCP Offers only from known server ports, preventing rogue DHCP servers from handing out malicious configurations (wrong gateway, wrong DNS). DHCP snooping is covered in NET202 (Network Security).
• Security: DNS poisoning and DNSSEC. If an attacker can inject false DNS records into a resolver's cache, they can redirect users to malicious servers. DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so resolvers can verify authenticity. DNS security is explored in NET202.
• Lease time design: Short leases (minutes) reclaim addresses quickly on guest networks with high device turnover. Long leases (days) reduce DHCP traffic on stable corporate networks. Choosing the right lease duration is a design decision that balances address efficiency against server load.

Guided Lab: Setting Up a DHCP Server and DNS Relay in Packet Tracer

Goal: Configure a Cisco router as a DHCP server for a local LAN and as a DHCP relay for a remote VLAN. Verify client addressing and test DNS resolution.

Topology

  [PC1] ---- [SW1] ---- [R1] ---- [SW2] ---- [PC2]
  VLAN 10               g0/0       g0/1        VLAN 20
  10.1.1.0/24                                  10.20.0.0/24

R1 serves as DHCP server for VLAN 10 (local scope)
R1 serves as DHCP relay for VLAN 20 → external DHCP server at 10.1.1.100
(or configure R1 with a second DHCP pool for VLAN 20)

Part A: Configure DHCP Server on R1

1. Exclude static addresses:
   R1(config)# ip dhcp excluded-address 10.1.1.1 10.1.1.10
2. Create the DHCP pool:
   R1(config)# ip dhcp pool VLAN10
R1(dhcp-config)# network 10.1.1.0 255.255.255.0
R1(dhcp-config)# default-router 10.1.1.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# lease 0 8 0
3. Configure R1 g0/0 interface:
   R1(config)# interface g0/0
R1(config-if)# ip address 10.1.1.1 255.255.255.0
R1(config-if)# no shutdown

Part B: Configure DHCP for VLAN 20

1. Exclude static addresses:
   R1(config)# ip dhcp excluded-address 10.20.0.1 10.20.0.10
2. Create the second pool:
   R1(config)# ip dhcp pool VLAN20
R1(dhcp-config)# network 10.20.0.0 255.255.255.0
R1(dhcp-config)# default-router 10.20.0.1
R1(dhcp-config)# dns-server 8.8.8.8
R1(dhcp-config)# lease 0 8 0
3. Configure R1 g0/1 interface:
   R1(config)# interface g0/1
R1(config-if)# ip address 10.20.0.1 255.255.255.0
R1(config-if)# no shutdown

Part C: Verify Client Configuration

1. Set PC1 and PC2 to DHCP mode (automatic addressing).
2. On PC1, run ipconfig /all and verify: IP is in 10.1.1.11-254, mask is /24, gateway is 10.1.1.1, DNS is 8.8.8.8.
3. On PC2, run ipconfig /all and verify: IP is in 10.20.0.11-254, mask is /24, gateway is 10.20.0.1.
4. On R1, run show ip dhcp binding and confirm both leases appear.
5. Ping from PC1 to PC2 to verify end-to-end connectivity through DHCP-assigned addresses.

Part D: DNS Test

1. From PC1, use nslookup www.google.com (if Packet Tracer supports it) or verify that the DNS server address was received correctly via DHCP.
2. Document the DNS server shown in ipconfig /all and confirm it matches the DHCP pool configuration.

Deliverable

A report containing: the DHCP pool configuration from show running-config, show ip dhcp binding output, ipconfig /all from both PCs, and a successful ping between the two DHCP-assigned hosts.

Week 10 Outcome Check

By the end of this week, you should be able to:

• Walk through the DHCP DORA process and explain the addressing used in each step
• Configure a DHCP server pool on a Cisco router with excluded addresses, gateway, and DNS settings
• Explain why DHCP relay is needed and configure ip helper-address
• Describe the DNS hierarchy from root to authoritative and explain recursive vs. iterative resolution
• Use nslookup, dig, and ipconfig to verify DNS and DHCP operation
• Diagnose APIPA addresses, scope exhaustion, relay failures, stale DNS caches, and rogue DHCP servers

Next week introduces the Cisco IOS CLI in depth — User EXEC, Privileged EXEC, Global Config modes, and essential management commands.

Hands-On Labs

Use these activities to build practical skills with DHCP and DNS configuration and troubleshooting.

Checkpoint Questions

1. List the four DHCP messages in order. For each, state whether it is broadcast or unicast and who sends it.
2. Why does the DHCP Discover use source IP 0.0.0.0 and destination IP 255.255.255.255?
3. What is the purpose of the GIADDR field in a relayed DHCP message? Why does the server need it?
4. A client receives a 169.254.x.x address. What does this tell you about the state of DHCP service on that subnet?
5. Explain the difference between a recursive DNS query and an iterative DNS query. Which one does your laptop send to its configured resolver?
6. What DNS record type maps a hostname to an IPv4 address? What type maps a hostname to an IPv6 address?
7. You can ping 8.8.8.8 but nslookup www.google.com fails. Is this a network problem or a DNS problem? What would you check?
8. Why is a rogue DHCP server a security concern? What parameters could a rogue server supply to redirect traffic through an attacker's machine?

Weekly Reflection

Reflection prompt (200-300 words):

This week covered the two services that most users take completely for granted. Reflect on what DHCP and DNS mean for network operations and design.

• Why do most users think "the internet is down" when the real problem is a DNS or DHCP failure? What does this tell you about where users experience the network?
• How does DHCP relay change the architecture options for where DHCP servers can be placed? What are the trade-offs between a centralized server with relays versus distributed servers on each subnet?
• What would happen to the internet if all DNS caching were turned off? What would the user experience look like?
• Why should DHCP and DNS be treated as security-critical services, not just convenience features?

A strong reflection should connect DHCP and DNS mechanics to the operational and security decisions that network engineers face in production environments.

Recommended References

• RFC 2131: Dynamic Host Configuration Protocol (DHCP) — the DHCP specification defining the DORA process, lease management, and relay behavior.
• RFC 1034 / RFC 1035: Domain Names — Concepts and Facilities / Domain Names — Implementation and Specification — the foundational DNS specifications defining the hierarchy, record types, and query/response format.
• RFC 3046: DHCP Relay Agent Information Option — describes how relay agents insert additional information (Option 82) into relayed DHCP messages.
• IANA DHCP Options Registry: DHCP and BOOTP Parameters — the authoritative list of DHCP option codes (Option 3 = Gateway, Option 6 = DNS, etc.).
• Cisco Networking Academy: Networking Basics — DHCP and DNS modules aligned with CCNA Day 34-35 objectives.
• Cloudflare Learning Center: What is DNS? — an accessible, well-illustrated explanation of DNS resolution with diagrams.
• Wireshark DHCP/DNS Analysis: Wireshark User Guide — reference for DHCP (bootp) and DNS display filters and protocol dissection.

Read RFC 2131 sections 3-4 (client-server protocol) alongside your Wireshark DORA capture. Matching the specification to live packets makes the protocol permanently understandable.

Week 10 Quiz

Test your understanding of the DHCP DORA process, DHCP relay, DNS hierarchy, record types, and troubleshooting both services.