DHCP and DNS on Cisco Networks: Roles, Relay, and ip helper-address

DHCP hands a host its network identity; DNS makes names usable instead of addresses. The CCNA asks you to keep their roles straight and to configure a router as a DHCP server and relay, and the relay part is where real understanding shows: DHCP discovery is broadcast, routers do not forward broadcasts, and yet every enterprise runs central DHCP servers several hops away from their clients. This article builds that exact scenario on real Cisco IOS XE (server on R1, relay on R2, client on R3) and reads the state on all three, as part of the IP Services complete guide.

DHCP vs DNS: Two Jobs, Often Confused

The link between them: one of the most important options DHCP hands out is which DNS servers to use. Get the DHCP pool's dns-server option wrong and every client on that subnet "has no internet" even though routing is perfect (nothing resolves).

DORA, and What the Relay Actually Does

A fresh client finds a server with four messages: Discover, Offer, Request, Ack. Discover and Request are broadcasts (the client has no address yet, and may not even know the server). Broadcasts die at the router, so on any subnet without a local DHCP server you configure the router's LAN interface as a relay agent with ip helper-address. The relay picks up the broadcast, stamps the receiving interface's address into the packet's giaddr (gateway address) field, and forwards it as unicast to the server. The server uses giaddr to pick the right pool, and replies unicast back to the relay, which delivers the answer to the client's LAN.

The Lab: Server, Relay, Client on Three Routers

R1 is the central DHCP server, two hops from the client LAN (10.0.40.0/24). Its pool:

ip dhcp excluded-address 10.0.40.1 10.0.40.9
ip dhcp pool LAN40
 network 10.0.40.0 255.255.255.0
 default-router 10.0.40.1
 dns-server 192.168.99.100
 domain-name pinglabz.lab

R2 owns the client LAN and relays toward R1 (1.1.1.1 is R1's loopback, reachable via OSPF):

R2#show run interface Ethernet0/3
interface Ethernet0/3
 description LAN40-DHCP-RELAY
 ip address 10.0.40.1 255.255.255.0
 ip helper-address 1.1.1.1
end

R3 plays the client with ip address dhcp on its interface. Now the state on all three, starting with the client:

R3#show ip interface brief | include Ethernet0/3
Ethernet0/3            10.0.40.10      YES DHCP   up                    up

R3#show dhcp lease | include IP|Lease|serv
Temp IP addr: 10.0.40.10  for peer on Interface: Ethernet0/3
   DHCP Lease server: 10.0.12.1, state: 5 Bound
   Lease: 86400 secs,  Renewal: 43200 secs,  Rebind: 75600 secs

Method DHCP, state Bound, and the three timers every DHCP client runs: renew at 50% of the lease (unicast to the original server), rebind at 87.5% (broadcast to any server), expire at 100% (start over with Discover). On the server, the lease appears in the binding table:

R1#show ip dhcp binding
IP address      Client-ID/              Lease expiration        Type       State      Interface
                Hardware address/
                User name
10.0.40.10      0063.6973.636f.2d61.    Jul 11 2026 10:38 PM    Automatic  Active     Ethernet0/1

R1#show ip dhcp pool
Pool LAN40 :
 Total addresses                : 254
 Leased addresses               : 1
 Excluded addresses             : 9
 Current index        IP address range                    Leased/Excluded/Total
 10.0.40.11           10.0.40.1        - 10.0.40.254       1     / 9     / 254

Notice the binding's Interface column says Ethernet0/1: that is where the relayed unicast arrived from R2, proof the broadcast-to-unicast conversion happened. The server statistics show the DORA conversation counters:

R1#show ip dhcp server statistics
Message              Received
DHCPDISCOVER         17
DHCPREQUEST          1

Message              Sent
DHCPOFFER            6
DHCPACK              1

(Seventeen Discovers for one lease? The client started broadcasting at boot, before OSPF had converged and before the relay could reach 1.1.1.1. Real networks show this pattern after power events, and it is normal: the client retries until the path exists.)

Beyond the Basic Pool: Reservations, Options, and Conflicts

Three pool features come up constantly in real deployments. A manual binding (DHCP reservation) pins a specific host to a specific address by its client identifier, giving you the stability of a static address with the central management of DHCP:

ip dhcp pool PRINTER-1
 host 10.0.40.50 255.255.255.0
 client-identifier 0100.1122.3344.55

Options carry vendor-specific bootstrap data beyond gateway and DNS. The two you will meet on Cisco networks: option 150 (TFTP server list for IP phones fetching their config) and option 43 (controller addresses for access points joining a wireless LAN controller). If phones or APs on a subnet will not come up, the pool's options are the first suspect.

And conflicts: before offering an address, the server pings it; if something answers, the address is quarantined in the conflict table rather than leased. A growing show ip dhcp conflict table almost always means someone has been hand-configuring static addresses inside the DHCP range, which is what excluded-address ranges are for.

The DNS Side on IOS

Routers are DNS clients too, and the CCNA expects the client-side commands. Point the router at a resolver and let it resolve names in ping/traceroute/logs:

ip name-server 192.168.99.100
ip domain lookup
ip domain name pinglabz.lab

ip domain lookup is on by default, which is why a typo at the CLI hangs while the router tries to resolve it as a hostname; many engineers disable it on lab boxes (no ip domain lookup, exactly what this lab's base config does) and enable it deliberately where name resolution is wanted. A router can even be a modest DNS server (ip dns server) for small sites, though in practice DNS service lives on dedicated infrastructure and the router's job is simply to hand out the right resolver addresses via its DHCP pools.

The DNS Records a Network Engineer Actually Touches

You do not need to run BIND to need DNS literacy. Four record types cover nearly every infrastructure conversation: A maps a name to an IPv4 address, AAAA to an IPv6 address, CNAME aliases one name to another (monitoring dashboards love pointing at CNAMEs so the backend can move), and PTR maps an address back to a name. PTR records are the sleeper: reverse lookups are what make your traceroutes readable, your syslog collector display hostnames, and some services (mail, strict SSH configs) actively check them. When the NOC says "traceroute shows weird names," someone's PTR zone is stale, not the routing. On the resolution path itself, remember the client asks a recursive resolver (the address DHCP handed out), and that resolver walks the authoritative hierarchy on the client's behalf; caching at every layer is why a DNS change "takes time" (the TTL on the record is the contract).

Troubleshooting the Chain

When a client gets no address, walk the chain in order: is the client actually sending Discovers (interface up, ip address dhcp present)? Does the LAN's router interface have the ip helper-address? Can the relay reach the server address (ping it sourced from the client-facing interface, since that becomes giaddr and the server's replies go there)? Does the server have a pool matching the giaddr subnet, with addresses left in it (show ip dhcp pool)? And if the client gets an address but "nothing works," check what came with the lease: wrong default-router or dns-server options break connectivity in ways that look like routing failures. debug ip dhcp server events on the server shows each DORA step live when you need the ground truth.

Key Takeaways

DHCP leases identity (address, gateway, DNS servers); DNS resolves names; the exam and real life both hinge on not blurring them. Relay agents (ip helper-address) convert client broadcasts to unicasts and stamp giaddr so a central server can serve every subnet, which the lab proved end to end: client Bound at 10.0.40.10, binding on the server two hops away, DORA counters ticking. Excluded ranges protect static addresses, the pool's options matter as much as the addresses, and lease timers (50% renew, 87.5% rebind) explain most "it fixed itself" stories. The rest of the operational services live in the IP Services complete guide.