LogoENEnglish

DHCP and DNS: Automatic Addressing and Name Resolution

Manually configuring an IP address on every device does not scale, and remembering numeric IP addresses for every service is impractical, which is why DHCP and DNS exist as essential supporting services in nearly every network. This article explains how DHCP automatically assigns IP addressing information, covers configuring a Cisco device as a DHCP server or relay agent, and explains how DNS resolves human-readable names into IP addresses.

DHCP ConfigurationDHCP RelayDNS Resolution

~6 دقیقه مطالعه · آخرین به‌روزرسانی ۱۸ شهریور ۱۴۰۵

Why Manual IP Configuration Does Not Scale

Manually configuring an IP address, subnet mask, default gateway, and DNS server on every device, discussed earlier in this series regarding IPv4 addressing, is manageable for a handful of routers and switches, but completely impractical for hundreds or thousands of end-user devices that join and leave a network constantly. DHCP (Dynamic Host Configuration Protocol) solves this by automatically assigning this information to devices as they connect.

The DHCP Process: DORA

A device requesting an address from a DHCP server goes through a four-step exchange commonly remembered by the acronym DORA.

DORA process:

1. Discover: the client broadcasts a request,
   since it has no IP address yet and does not
   know where the DHCP server is

2. Offer: one or more DHCP servers respond with
   an offered IP address and configuration

3. Request: the client broadcasts a request for
   one specific offer (usually the first received)

4. Acknowledge: the chosen server confirms the
   assignment and the client begins using it

This entire exchange relies on broadcast traffic, discussed earlier in this series, since the client has no IP address of its own yet and cannot send a directed (unicast) request to a specific server address.

Configuring a Cisco Device as a DHCP Server

Router(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.10
-- reserves addresses that should never be
-- dynamically assigned (typically the gateway
-- and other statically configured devices)

Router(config)# ip dhcp pool LAN-POOL
Router(dhcp-config)# network 192.168.1.0 255.255.255.0
Router(dhcp-config)# default-router 192.168.1.1
Router(dhcp-config)# dns-server 8.8.8.8
Router(dhcp-config)# lease 7

-- lease 7 sets the address lease time to 7 days,
-- after which a client must renew its assignment

The ip dhcp excluded-address command must be configured before creating the pool for it to be effective, and is easy to forget — without it, the DHCP server could accidentally offer an address already statically assigned to a router interface or server, causing an IP address conflict.

The Problem: DHCP Broadcasts Don't Cross Routers

Since the DHCP discovery process relies entirely on broadcast traffic, and routers do not forward broadcasts between subnets by default, discussed earlier in this series regarding broadcast domains, a DHCP client on one subnet cannot directly reach a DHCP server located on a different subnet.

DHCP Relay: Bridging the Gap Across Subnets

Rather than deploying a separate DHCP server on every subnet, a DHCP Relay Agent, configured on the router interface facing the client's subnet, converts the client's broadcast into a unicast packet directed specifically at the remote DHCP server.

Router(config)# interface gigabitethernet 0/1
Router(config-if)# ip helper-address 192.168.1.10

-- 192.168.1.10 is the address of the actual
-- DHCP server, located on a different subnet
-- than this interface's own network

The ip helper-address command is applied to the interface closest to the requesting clients, and the router forwards the client's DHCP broadcast as a unicast packet to the specified server, then relays the server's response back to the client — allowing a single centralized DHCP server to serve clients across many separate subnets.

Verifying DHCP Operation

Router# show ip dhcp binding

IP address       Client-ID/Hardware address    Lease expiration
192.168.1.11      0100.5056.aa11.22             Jul 15 2026 10:30 AM
192.168.1.12      0100.5056.bb33.44             Jul 15 2026 11:15 AM

Router# show ip dhcp pool LAN-POOL

show ip dhcp binding lists every address currently leased out, along with the requesting device's identifier and when the lease expires — the primary command for confirming DHCP is actually assigning addresses correctly and for identifying which physical device holds a specific IP address.

Why Numeric IP Addresses Alone Are Impractical

Even with addressing automated by DHCP, requiring users to remember and type numeric IP addresses for every service they use would be deeply impractical — nobody wants to type an IP address to visit a website. DNS (Domain Name System) solves this by translating human-readable domain names into the IP addresses computers actually use to communicate.

How DNS Resolution Works

Simplified DNS resolution process:

1. User's device queries a configured DNS server
   for the IP address of "example.com"

2. If the DNS server does not already have this
   answer cached, it queries other DNS servers
   in a hierarchy (root servers, then top-level
   domain servers, then the domain's own
   authoritative server) until it finds the answer

3. The DNS server returns the resolved IP address
   to the user's device, which then connects
   directly to that address

Configuring DNS on a Cisco Device

Router(config)# ip domain-name example.com
Router(config)# ip name-server 8.8.8.8 8.8.4.4

-- allows the router itself to resolve domain
-- names, useful for commands like ping or
-- telnet that accept a hostname instead of
-- requiring a numeric IP address

Router# ping example.com
Translating "example.com"...domain server (8.8.8.8) [OK]

Configuring multiple DNS servers, as shown above, provides redundancy — if the first server does not respond, the device automatically tries the next one, avoiding a total loss of name resolution if a single DNS server becomes unreachable.

Why DHCP and DNS Are Essential Supporting Services

Neither DHCP nor DNS is a routing or switching protocol in the sense of the topics covered elsewhere in this series, but both are essential supporting services without which a modern network would be effectively unusable at any real scale — manually configuring every device's IP address and requiring users to memorize numeric addresses for every service simply does not work beyond a handful of devices. Fluency with configuring, relaying, and troubleshooting both services is a core, everyday skill for any network administrator.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه
مقاله‌ی قبلیمقاله‌ی بعدی