RedTeam Nexus Labs
Module 10 · Lesson 04 // DHCP

addressing workflow

DHCP · Networking

Freereading · 10 min
On this page
  1. Overview
  2. Learning objectives
  3. Core concept
  4. How it works
  5. Practical example
  6. Cybersecurity relevance
  7. Common mistakes
  8. Key takeaways
  9. Check your understanding
LESSON

Overview

This lesson connects DHCP back to the addressing and DNS concepts from earlier modules, showing the complete workflow a device goes through — from joining a network to successfully loading a website. It is where automatic configuration, addressing, and name resolution meet.

Learning objectives

  • Sequence the steps from joining a network to reaching a service.
  • Show how DHCP, addressing, ARP, and DNS fit together.
  • Diagnose where the workflow can break.

Core concept

When a device joins a network and a user opens a site, several subsystems cooperate in order:

  1. DHCP assigns the device its IP address, mask, gateway, and DNS servers.
  2. The device now has valid addressing and knows its gateway (for off-network traffic).
  3. The user requests a name; DNS resolves it to an IP (using the DHCP-provided DNS server).
  4. To send the packet, the device uses ARP to find the MAC of either the destination (if local) or the gateway (if remote).
  5. The packet is delivered; the transport connection (e.g. TCP handshake) proceeds and the page loads.

How it works

Each step depends on the previous one. DHCP must succeed first, because without an IP, gateway, and DNS server nothing else can happen. Correct addressing lets the device decide local vs remote. DNS (pointed to by DHCP) turns the name into an address. ARP resolves the next-hop MAC so the frame can actually be sent. This chain is exactly why "I just connected but nothing works" problems are diagnosed step by step.

Practical example

A laptop joins Wi-Fi and the user opens www.example.com:

  1. DHCP leases 192.168.1.50, gateway 192.168.1.1, DNS 192.168.1.1.
  2. The laptop has working addressing and a known gateway.
  3. It asks the DNS server for www.example.com → gets an IP.
  4. That IP is on another network, so the laptop ARPs for the gateway's MAC.
  5. It sends the packet to the gateway, the TCP handshake completes, and the page loads.

Cybersecurity relevance

Seeing the full chain clarifies where an attacker can interfere: a rogue DHCP server can hand out a malicious gateway or DNS at step 1; DNS spoofing can falsify step 3; ARP poisoning can redirect step 4 to an attacker's machine. Each is a man-in-the-middle opportunity at a different stage. Defenders and testers reason about this workflow to locate where trust is established and where it can be subverted.

Common mistakes

  • Assuming connectivity is one step — it is a chain (DHCP → addressing → DNS → ARP → connection).
  • Overlooking that DHCP supplies the DNS server, so a bad DHCP lease can poison name resolution.
  • Not diagnosing step by step, making "nothing works" problems harder than they need to be.

Key takeaways

  • Joining a network and reaching a service is a chain: DHCP config → valid addressing → DNS resolution → ARP for next hop → transport connection.
  • Each step depends on the previous, which is why connectivity issues are diagnosed sequentially.
  • The chain exposes distinct man-in-the-middle points (rogue DHCP, DNS spoofing, ARP poisoning), one at each stage.

Check your understanding

  • Put these in order for a device loading a remote website: ARP for gateway, DHCP lease, DNS resolution, TCP handshake.
  • If DHCP hands out a malicious DNS server, which later step is compromised and how?
FINISH THIS LESSON

Sign in to save your progress.

Previousreservations