DHCP and DNS Explained for Beginners: DORA, Scopes, DHCP Relay and How Name Resolution Works

DHCP and DNS Basics: How Devices Get IP Addresses and Resolve Names in Real Networks

When we first check whether a network is working, we usually measure it by the cable, Wi-Fi, and the question “Is it getting an IP?” But if you pay a bit more attention, you realize this: even if devices are connected, if DHCP and DNS aren’t working properly, everything feels like it’s “half-working.” From the user’s side, this turns into a very familiar set of complaints:

“Wi-Fi is connected but there’s no internet.”
“Some websites open, some don’t.”
“I can’t connect to the application server.”
“VPN connects, but the intranet won’t load.”

In these kinds of problems, the physical connection is often fine. The issue is usually on the side of the network’s two foundational services: address distribution (DHCP) and name resolution (DNS). DHCP gives devices “identity and a path.” DNS “translates names into addresses.” You can think of these two as the network’s invisible infrastructure: you don’t see them, but if they’re missing, everyone stumbles.

In this article, I’ll first explain DHCP (with the DORA logic), then DNS (with forward/reverse and practical behaviors), then DHCP Relay as part of the natural flow of “How does DHCP work across subnets?” At the end, I’ll add the “Where do you start when there’s a problem?” section.

1) Let’s build the big picture first: what happens when a device joins a network?

When you plug a new device into the network (or connect it to Wi-Fi), several things must be correct at the same time for it to “reach the internet”:

The device must have an IP address
It must know which subnet it’s in (subnet mask/prefix)
It must know a default gateway to leave the subnet
It must know a DNS server to resolve names

A device can receive this information manually or automatically. At home, it usually works automatically — and that automatic distribution is provided by DHCP.

2) What is DHCP? Saying “it gives IPs” is incomplete

Most people learn DHCP as “the service that distributes IP addresses.” That’s true — but DHCP’s real value is that it distributes more than just an IP.

DHCP usually provides devices with:

IP address
Subnet mask / prefix
Default gateway
DNS servers
(Optional) additional options like domain name, NTP, PXE boot, etc.

So DHCP actually ensures a device joins the network with the “right identity” and the “right direction.” That’s why when DHCP breaks, it’s not only “no IP.” Sometimes there is an IP, but the mask is wrong, the gateway is wrong, or the DNS is wrong. The user then describes it as “the internet is broken.”

3) DORA: the order of DHCP conversation (and why it sometimes gets stuck)

The best framework to explain how DHCP works is DORA:

Discover → Offer → Request → Acknowledge

Once this flow is settled in your mind, troubleshooting DHCP becomes much easier.

Discover:
The device broadcasts: “I’m new here, is there an IP for me?”
Offer:
The DHCP server responds: “Yes, I can give you this IP.”
Request:
The device replies: “Okay, I want this IP.”
ACK (Acknowledge):
The DHCP server says: “Approved, this IP is yours,” and the lease begins.

Here’s the critical point: Discover is generally a broadcast. Meaning the DHCP server is “announced” within the same Layer 2 area (the same VLAN/broadcast domain).

Keep this sentence in mind:
DHCP’s core behavior starts with a broadcast.
And this naturally leads us to DHCP Relay in a moment.

4) Lease logic: an IP is not “permanent,” it’s rented

DHCP does not assign IPs forever. There is a lease time: the IP is rented for a specific period. This matters for two reasons:

The IP pool is used efficiently (not every device holds a permanent IP)
IPs from devices that leave the network are freed up and can be reused

But in practice, situations like these show up:

If the lease time is too long: IPs stay occupied unnecessarily
If the lease time is too short: devices keep renewing constantly (unnecessary traffic and sometimes issues)

For a beginner, it’s enough to know this: leases are both a source of order and a potential source of problems.

5) What is a DHCP scope, and why should it be considered together with subnetting?

In the subnetting article, we talked about “network boundaries.” DHCP’s scope logic is directly tied to those boundaries.

Generally, each subnet needs its own DHCP scope,
because each subnet’s IP range, mask, and gateway are different.

Example:

VLAN 10 / Subnet: 192.168.10.0/24 → Gateway: 192.168.10.1
VLAN 20 / Subnet: 192.168.20.0/24 → Gateway: 192.168.20.1

If the DHCP settings for these two subnets get mixed into one scope, devices receive the wrong gateway, and the “some things work, some things don’t” scenario begins.

The relationship between subnetting and DHCP is very clear here:

Subnetting draws the boundary; DHCP fills the inside of that boundary correctly.

6) DHCP Relay: what if the DHCP server is in another subnet?

Now we reach the most critical part. We said DHCP Discover is a broadcast. Broadcast packets do not pass through a router, because a router is the boundary between subnets and does not carry broadcasts to the other side.

So we have to answer this question:
If the DHCP server is in another subnet, how will the device get an IP?

This is exactly what DHCP Relay solves.

The logic of DHCP Relay is very simple:

The client sends a DHCP Discover as a broadcast.
The relay (usually a router or L3 switch) receives this request.
It forwards the request to the DHCP server as a unicast.
It carries the DHCP server’s response back to the client.

So the relay acts like a “translator,” moving DHCP messages between subnets.

Once this concept clicks, many things fall into place:

“Why don’t we run a DHCP server in every VLAN?” Because we manage it with a centralized DHCP server + relay.
“Why don’t clients in some VLANs get an IP?” Because the relay configuration may be missing/incorrect on that VLAN’s L3 interface.

DHCP Relay is commonly used in setups like:

One centralized DHCP server at HQ
Multiple VLANs/subnets
“Helper/relay” configured per VLAN on the router/L3 switch

7) DNS: without the network’s “address book,” both internet and internal services become painful

DHCP assigns IP addresses; DNS makes life easy for people and applications.

Because nobody wants to connect to a server as “10.20.30.40.” People prefer names like:

intranet.company.local
fileserver01
mail.company.com

DNS’s core job is:

Mapping name → IP (forward lookup)

But DNS’s practical impact is not limited to “websites open.” Especially in enterprise environments:

Active Directory
Domain join
Kerberos
Many service discovery mechanisms

depend heavily on DNS. When DNS breaks, even if “the internet seems to work,” everything internal can fall apart.

8) How does DNS work? Let’s anchor the idea of “forward” and “reverse”

Forward lookup (most common)

server01.company.local → 10.10.10.50

Reverse lookup (less discussed, but important)

10.10.10.50 → server01.company.local

Reverse lookup becomes important especially for:

Seeing names instead of IPs in logs
Certain security/application checks
Some scenarios like mail systems

For a beginner, it’s enough to know this for now:

Forward is needed every day
Reverse is needed sometimes — but it’s not “never needed”

9) DNS caching and TTL: why is it “fixed yesterday, broken today?”

The reason DNS can sometimes feel annoying is caching. DNS answers aren’t asked just once; both clients and DNS servers keep a cache. That cache has a duration: TTL.

This means:

You changed a DNS record.
But some devices may still keep going to the old IP.
Because the cache hasn’t expired yet.

This is very common in situations like “the server IP changed” or “we moved the service.” That’s why, instead of expecting “everyone should see it immediately,” understanding TTL/caching is important when making DNS changes.

10) How do DHCP + DNS work together?

For a smooth experience on the network, DHCP and DNS must be aligned.

DHCP gives devices the DNS server address.
The device sends its queries to that DNS server.
In enterprise environments, DHCP can sometimes automatically register device names in DNS (Dynamic DNS / DDNS).

If this relationship breaks, you can get weird scenarios like:

You get an IP but “websites won’t open” → wrong DNS might be delivered
You get an IP, ping works by IP but not by name → DNS/lookup issue
Some devices work and others don’t → different scopes may be handing out different DNS servers

So it’s better to see DHCP and DNS not as two separate topics, but as two connected foundational services.

11) A mini checklist: if something doesn’t work, where do you start?

As a beginner, one of the most useful things is: what order do I check things in when there’s an issue?

A) If the device cannot get an IP

Is there link? (physical)
Is it in the same VLAN? (is the port in the correct VLAN?)
Is the DHCP scope exhausted? (the pool may be full)
Is the DHCP server reachable?
Is DHCP Relay required? (if the server is in another subnet)

B) If there is an IP but no internet

Is the gateway correct?
Is DNS correct?
Does ping work by IP? (e.g., ping the gateway)
Does name resolution work? (e.g., ping/lookup by hostname)

C) If some websites open and some don’t

It could be DNS caching/TTL
If there are multiple DNS servers, there could be inconsistency
The wrong DNS might be distributed (e.g., public vs internal, or vice versa)

Once you internalize this order, “random guessing” decreases and problems are found faster.

Closing: once you understand DHCP and DNS, the network becomes more “predictable”

At first glance, DHCP and DNS look like “services,” but they actually define the network’s fundamental behavior. DHCP brings the device into the network; DNS ensures it goes to the right place. And as subnets grow, we use DHCP Relay to carry this order between subnets.

Once these topics click, later topics like security (Firewall/NAT/DMZ) or more advanced routing also become easier. Because when you ask “Why isn’t the packet going through?” you’ve already built not only the direction correctly, but also the addressing and naming.