CCNA DHCP & DNS Lab — Server Config, Relay & Troubleshooting

What DHCP and DNS are and why they matter in 2026

Dynamic Host Configuration Protocol (DHCP) automates IP address assignment to devices on a network, eliminating manual configuration errors and reducing administrative overhead. Domain Name System (DNS) translates human-readable domain names like networkershome.com into IP addresses that routers and switches understand. Together, these protocols form the foundation of every enterprise network—from the 800+ hiring partners we work with at Networkers Home to the smallest branch office. Without DHCP, network administrators would manually configure every laptop, phone, and IoT sensor; without DNS, users would memorize IP addresses instead of typing URLs. In 2026, both protocols remain critical exam topics in the CCNA 200-301 Study Guide and daily operational tasks for network engineers at Cisco India, HCL, Akamai, and Aryaka.

DHCP operates at the application layer but relies on UDP ports 67 (server) and 68 (client). DNS uses UDP port 53 for queries under 512 bytes and TCP port 53 for zone transfers or large responses. Both protocols scale from home routers to data centers with thousands of endpoints. Mastering DHCP and DNS configuration, relay agents, and troubleshooting distinguishes junior engineers from those who earn ₹6-9 LPA roles at Movate, Wipro, or TCS within months of completing structured training.

How DHCP works: the DORA process under the hood

DHCP follows a four-step lease negotiation called DORA: Discover, Offer, Request, Acknowledge. When a client boots without an IP address, it broadcasts a DHCPDISCOVER message to 255.255.255.255 on UDP port 67. Every DHCP server on the local subnet receives this broadcast and responds with a DHCPOFFER containing an available IP address, subnet mask, default gateway, DNS server addresses, and lease duration. The client selects one offer—typically the first received—and broadcasts a DHCPREQUEST to inform all servers which offer it accepted. The chosen server replies with a DHCPACK, finalizing the lease and logging the binding in its database. Rejected servers withdraw their offers silently.

Lease timers govern address reuse. A typical enterprise lease lasts 24 hours, though Cisco IOS routers default to one day when configured as DHCP servers. At 50 percent of the lease time (T1 timer), the client unicasts a renewal request to the original server. If that server is unreachable, the client waits until 87.5 percent (T2 timer) and broadcasts a renewal to any available server. If the lease expires without renewal, the client must release the address and restart DORA. In our HSR Layout lab, we simulate server failures during T1 and T2 windows to teach troubleshooting under real-world conditions—scenarios that appear in CCNA practicals and production networks at Barracuda and Aryaka.

DHCP options extend basic functionality. Option 3 specifies the default gateway, Option 6 lists DNS servers, Option 15 sets the DNS domain name, and Option 51 defines lease duration. Cisco IOS routers acting as DHCP servers configure these via the ip dhcp pool command set. Option 82 (relay agent information) inserts circuit-id and remote-id sub-options when a relay forwards requests across subnets, enabling centralized servers to assign addresses based on client location. Understanding option fields is essential for troubleshooting why clients receive incorrect gateways or cannot resolve domain names—a frequent interview question at Cisco India and Infosys.

How DNS resolution works: recursive and iterative queries

DNS resolution begins when an application calls a resolver library, which checks the local cache for a recent answer. If the cache misses, the resolver sends a recursive query to a configured DNS server—often the ISP's resolver or a public service like 8.8.8.8. A recursive query obligates the server to return either the final answer or an error; the server cannot redirect the client to another nameserver. The recursive server starts at a root nameserver (one of 13 logical clusters labeled A through M), which responds with a referral to the appropriate top-level domain (TLD) server (.com, .in, .org). The recursive server then queries the TLD server, receiving a referral to the authoritative nameserver for the target domain. Finally, the authoritative server returns the A record (IPv4 address) or AAAA record (IPv6 address), which the recursive server caches and forwards to the client.

Iterative queries shift resolution responsibility to the client. When a server responds with a referral instead of an answer, the client must query the next server in the chain. Recursive resolvers use iterative queries internally when contacting root, TLD, and authoritative servers. Caching dramatically reduces query load: a well-tuned resolver caches answers for the duration specified in the record's Time To Live (TTL) field, typically 300 to 86400 seconds. Negative caching stores NXDOMAIN (non-existent domain) responses to prevent repeated lookups for typos or decommissioned hosts.

DNS record types serve distinct purposes. A records map hostnames to IPv4 addresses, AAAA records to IPv6 addresses, CNAME records create aliases, MX records direct email routing, NS records delegate subdomains to other nameservers, and PTR records enable reverse lookups (IP to hostname). SOA records define zone metadata including the primary nameserver, administrator email, serial number, and refresh intervals. In the best CCNA course in Bangalore, we configure Cisco IOS routers as caching DNS forwarders and demonstrate how incorrect record types cause application failures—knowledge that separates candidates in technical rounds at Accenture and IBM.

Configuring a Cisco IOS router as a DHCP server

Cisco IOS routers function as DHCP servers for small to medium networks. The configuration begins by defining an IP address pool with a unique name, then specifying the network range, excluded addresses, default gateway, DNS servers, and lease duration. The following example configures a pool named VLAN10 for the 192.168.10.0/24 subnet:

Router(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.10
Router(config)# ip dhcp pool VLAN10
Router(dhcp-config)# network 192.168.10.0 255.255.255.0
Router(dhcp-config)# default-router 192.168.10.1
Router(dhcp-config)# dns-server 8.8.8.8 8.8.4.4
Router(dhcp-config)# domain-name networkershome.local
Router(dhcp-config)# lease 7
Router(dhcp-config)# exit

The ip dhcp excluded-address command reserves addresses 192.168.10.1 through 192.168.10.10 for static assignment to servers, printers, or network devices. The pool assigns addresses from 192.168.10.11 to 192.168.10.254. The lease command sets a seven-day duration; omitting this parameter defaults to one day. Multiple pools coexist on a single router, each serving a different VLAN or subnet. The router listens on all interfaces where ip helper-address is not configured, responding to DHCPDISCOVER broadcasts received locally.

Verification commands confirm server operation. show ip dhcp binding lists active leases with client MAC addresses, assigned IPs, lease expiration times, and binding types (automatic, manual, or expired). show ip dhcp pool VLAN10 displays pool utilization, total addresses, leased addresses, and pending offers. show ip dhcp conflict reveals address conflicts detected via gratuitous ARP or ICMP ping before assignment. debug ip dhcp server events logs DORA messages in real time, essential for diagnosing why clients fail to obtain addresses. In our 24×7 rack access lab, students configure multi-pool scenarios and simulate conflicts to build troubleshooting muscle memory before joining Cisco India or Akamai teams.

Configuring DHCP relay agents for multi-subnet networks

DHCP broadcasts do not cross router boundaries by default, requiring relay agents (also called DHCP helpers) to forward client requests to centralized servers. A relay agent receives DHCPDISCOVER broadcasts on one interface, encapsulates them in unicast UDP packets, and forwards them to a configured server IP address. The server responds to the relay agent, which broadcasts the DHCPOFFER back to the client's subnet. This architecture centralizes address management, reducing the number of DHCP servers and simplifying policy enforcement across branch offices.

Configuring a relay agent on a Cisco router requires a single command on each interface facing client subnets:

Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip helper-address 10.1.1.100
Router(config-if)# exit

This configuration forwards DHCP requests received on GigabitEthernet0/1 to the server at 10.1.1.100. The ip helper-address command also forwards TFTP (UDP 69), DNS (UDP 53), Time (UDP 37), NetBIOS Name Service (UDP 137), and NetBIOS Datagram Service (UDP 138) by default. To restrict forwarding to DHCP only, disable other services with no ip forward-protocol udp followed by the specific port number. Multiple helper addresses on a single interface enable redundancy; the router forwards requests to all configured servers, and the client selects the first offer received.

Relay agents insert Option 82 (relay agent information) into forwarded requests, allowing servers to assign addresses based on client location. The giaddr field in the DHCP header contains the relay agent's interface IP address, which the server uses to select the appropriate address pool. Troubleshooting relay failures involves verifying IP connectivity between the relay agent and server with ping, confirming the helper address configuration with show running-config interface, and capturing packets with debug ip udp to observe forwarded messages. During our 4-month paid internship at the Network Security Operations Division, interns troubleshoot relay misconfigurations in multi-site topologies mirroring deployments at HCL and Wipro.

Configuring Cisco IOS routers as DNS forwarders and resolvers

Cisco IOS routers cache DNS responses and forward queries to upstream resolvers, reducing latency for frequently accessed domains. Enabling DNS services requires three commands: activating the DNS server, specifying upstream nameservers, and optionally defining static host entries. The following configuration enables DNS forwarding:

Router(config)# ip dns server
Router(config)# ip name-server 8.8.8.8 8.8.4.4
Router(config)# ip host router1.networkershome.local 192.168.1.1

The ip dns server command activates the router's DNS proxy, listening on UDP and TCP port 53. The ip name-server command specifies upstream resolvers; the router forwards queries it cannot answer from cache or static entries. The ip host command creates a static A record, useful for internal devices without authoritative DNS zones. Clients configure the router's interface IP as their DNS server, and the router handles recursive resolution on their behalf.

DNS caching improves performance and reduces upstream query load. The router caches positive responses (A, AAAA, CNAME records) and negative responses (NXDOMAIN) for the TTL specified in each record. show ip dns cache displays cached entries with remaining TTL values. clear ip dns cache flushes all entries, forcing fresh lookups—useful after DNS record updates. debug ip dns view logs query and response details, revealing whether the router answered from cache, static entries, or upstream servers. In our HSR Layout lab, we configure routers as split-horizon DNS servers, returning internal addresses for networkershome.local queries and forwarding external queries to public resolvers—a pattern common in Cisco India and Aryaka production networks.

DHCP and DNS troubleshooting: systematic diagnosis

DHCP troubleshooting begins by verifying physical and data-link connectivity. Use show ip interface brief to confirm the client-facing interface is up/up and has an IP address in the correct subnet. Check VLAN assignments with show vlan brief on switches, ensuring the client port belongs to the expected VLAN. If the router acts as a DHCP server, verify the pool configuration with show ip dhcp pool and confirm no address exhaustion. If using a relay agent, test connectivity to the DHCP server with ping and verify the helper address with show running-config interface.

Client-side diagnostics vary by operating system. On Windows, ipconfig /release drops the current lease, and ipconfig /renew initiates DORA. ipconfig /all displays the DHCP server address, lease obtained and expiration times, and configured DNS servers. On Linux, dhclient -r releases the lease, and dhclient renews it. journalctl -u NetworkManager or cat /var/log/syslog reveal DHCP client logs. If a client receives an address from an unexpected server, rogue DHCP detection is necessary—use show ip dhcp binding on all routers and enable DHCP snooping on switches to block unauthorized servers.

DNS troubleshooting isolates resolver, network, or authoritative server issues. Use nslookup or dig to query specific nameservers, bypassing the client's configured resolver. If nslookup networkershome.com 8.8.8.8 succeeds but the default resolver fails, the client's DNS server configuration is incorrect. If all queries fail, verify IP connectivity to the DNS server with ping and traceroute. On Cisco routers, show ip dns view displays cache contents, and debug ip dns view logs query processing. Common pitfalls include firewall rules blocking UDP/TCP 53, incorrect forwarder addresses, and expired cached NXDOMAIN responses. During technical interviews at Cisco India and Infosys, candidates who demonstrate methodical troubleshooting—testing one layer at a time—consistently outperform those who guess randomly.

DHCP vs DNS: complementary roles in network automation

DHCP and DNS solve different problems but integrate tightly in modern networks. DHCP automates IP address assignment, subnet masks, default gateways, and DNS server addresses, eliminating manual configuration errors. DNS translates domain names to IP addresses, enabling users to access resources by memorable names instead of numeric addresses. A client without DHCP can still resolve domain names if manually configured with a DNS server address, but loses automatic gateway and subnet configuration. A client without DNS can reach resources by IP address but cannot browse websites or resolve hostnames.

Dynamic DNS (DDNS) bridges DHCP and DNS by automatically updating DNS records when DHCP assigns or renews an address. Microsoft Active Directory integrates DDNS natively; Cisco IOS routers support DDNS updates via the ip dhcp pool command with update dns and update arp options. DDNS ensures internal hostnames resolve correctly even as devices move between subnets or receive new addresses, critical for VoIP phones, printers, and IoT sensors in enterprise networks at Akamai and Aryaka.

Real-world deployment scenarios at Cisco India and Akamai

At Cisco India's Bengaluru campus, centralized DHCP servers assign addresses to thousands of endpoints across VLANs, with relay agents on distribution-layer switches forwarding requests. Separate pools serve employee workstations, guest Wi-Fi, IP phones, and building automation systems, each with distinct lease durations and option sets. IP phones receive Option 150 (TFTP server address) to download configuration files from Cisco Unified Communications Manager. Guest networks use short leases (one hour) to reclaim addresses quickly, while employee devices receive 24-hour leases for stability. DNS servers run BIND on Linux, with primary and secondary nameservers in different data centers for redundancy. Split-horizon DNS returns internal addresses for intranet resources and public addresses for external queries, enforced via view statements in BIND configuration.

Akamai's content delivery network relies on DNS for traffic steering, directing clients to the nearest edge server based on geographic location and server load. Akamai's authoritative nameservers return different A records depending on the resolver's IP address, minimizing latency and balancing load across thousands of edge nodes. DHCP plays a smaller role in Akamai's infrastructure, primarily assigning addresses to internal management networks and employee devices. However, Akamai's customers—including e-commerce platforms and streaming services—depend on DHCP for end-user connectivity, making DHCP troubleshooting a critical skill for support engineers.

In our 4-month paid internship at the Network Security Operations Division, interns configure DHCP snooping on Cisco Catalyst switches to prevent rogue DHCP servers, enable Dynamic ARP Inspection (DAI) to block ARP spoofing, and deploy DNS security extensions (DNSSEC) to validate record authenticity. These hands-on tasks mirror responsibilities at Barracuda, Movate, and Wipro, where junior engineers maintain DHCP and DNS infrastructure for enterprise clients. Interns who complete the program receive an 8-month verified experience letter, accelerating placement into ₹6-9 LPA roles at our 800+ hiring partners.

How DHCP and DNS connect to CCNA, CCNP, and CCIE syllabi

The CCNA 200-301 exam allocates approximately 10 percent of questions to IP services, including DHCP and DNS configuration, verification, and troubleshooting. Candidates must configure Cisco IOS routers as DHCP servers, implement relay agents, interpret show ip dhcp binding output, and diagnose common failures such as address exhaustion and relay misconfiguration. DNS coverage includes configuring routers as DNS forwarders, verifying cache contents, and understanding record types (A, AAAA, CNAME, MX). Hands-on labs test the ability to configure multi-pool DHCP scenarios and troubleshoot clients that fail to obtain addresses or resolve domain names.

CCNP Enterprise (ENCOR 350-401 and ENARSI 300-410) expands DHCP and DNS topics to include DHCP snooping, Option 82 processing, DHCPv6 for IPv6 networks, and DNS security. ENCOR covers DHCP snooping configuration on Cisco Catalyst switches, binding table verification, and integration with Dynamic ARP Inspection and IP Source Guard. ENARSI emphasizes troubleshooting complex relay scenarios, diagnosing DHCP conflicts, and analyzing packet captures with Wireshark. DNS topics include DNSSEC validation, split-horizon DNS design, and troubleshooting resolution failures in multi-site networks.

CCIE Enterprise Infrastructure (v1.1) and CCIE Security (v6.0) require expert-level DHCP and DNS knowledge. CCIE Enterprise candidates configure DHCP failover, implement DHCPv6 prefix delegation, and troubleshoot relay agents in MPLS VPN environments. CCIE Security candidates deploy DNS-based blackhole lists (DNSBL), configure DNS over HTTPS (DoH) and DNS over TLS (DoT) for privacy, and mitigate DNS amplification attacks using rate limiting and response rate limiting (RRL). Both tracks test the ability to diagnose failures under time pressure using only CLI commands and packet captures—skills honed in the best CCNA course in Bangalore and refined through our 24×7 lab access.

Common pitfalls and interview gotchas

Address exhaustion occurs when a DHCP pool runs out of available addresses, causing new clients to fail DORA. Administrators often overlook excluded addresses, reserving too few IPs for dynamic assignment. During interviews at Cisco India and HCL, candidates who suggest expanding the pool, reducing lease duration, or reclaiming expired leases demonstrate operational maturity. Another pitfall is configuring the wrong default gateway in the DHCP pool, causing clients to obtain addresses but fail to reach external networks. Verifying the gateway with show ip dhcp pool and testing client connectivity with ping from the client to the gateway isolates this issue quickly.

Relay agent misconfigurations prevent DHCP requests from reaching centralized servers. Forgetting to configure ip helper-address on client-facing interfaces is the most common mistake. Even when configured, incorrect server IP addresses or routing failures between the relay agent and server cause silent failures. Candidates who describe testing relay connectivity with ping and capturing packets with debug ip udp stand out in technical rounds. Another gotcha is multiple helper addresses on a single interface; the router forwards requests to all servers, and clients may receive offers from unintended servers, causing unpredictable gateway or DNS assignments.

DNS cache poisoning exploits vulnerabilities in recursive resolvers, injecting false records that redirect users to malicious sites. Enabling DNSSEC validation on resolvers prevents this attack by cryptographically verifying record authenticity. However, DNSSEC requires authoritative nameservers to sign zones with DNSSEC keys, and many small organizations skip this step. Interviewers at Akamai and Barracuda probe candidates' understanding of DNSSEC's trust chain, from root zone signing to individual record validation. Candidates who explain the DS (Delegation Signer) and RRSIG (Resource Record Signature) record types demonstrate advanced knowledge.

Rogue DHCP servers on enterprise networks assign incorrect gateways or DNS servers, enabling man-in-the-middle attacks. DHCP snooping on Cisco Catalyst switches prevents this by allowing DHCP responses only from trusted ports. Configuring snooping requires enabling the feature globally, designating trusted ports (uplinks to legitimate servers), and rate-limiting untrusted ports to prevent denial-of-service attacks. Candidates who describe this multi-step process and mention the binding table's role in Dynamic ARP Inspection impress interviewers at Infosys and TCS.

Frequently asked questions

What happens if a DHCP client cannot reach the server during lease renewal?

At 50 percent of the lease duration (T1 timer), the client unicasts a renewal request to the original DHCP server. If the server is unreachable, the client retries periodically until 87.5 percent of the lease (T2 timer), then broadcasts a renewal request to any available server. If no server responds before the lease expires, the client releases the address and restarts the DORA process. In production networks, redundant DHCP servers or relay agents to backup servers prevent this scenario. During our lab sessions, we simulate server failures to teach students how to diagnose and recover from renewal failures using show ip dhcp binding and client-side logs.

Can a Cisco router act as both a DHCP server and a relay agent simultaneously?

Yes, a Cisco router can serve DHCP requests on some interfaces while relaying requests from other interfaces to external servers. For example, a branch office router might serve VLAN 10 locally using ip dhcp pool VLAN10 while relaying VLAN 20 requests to a data center server using ip helper-address on the VLAN 20 interface. The router processes DHCPDISCOVER messages based on the receiving interface: if a pool matches the subnet, the router responds directly; otherwise, it forwards the request to configured helper addresses. This hybrid configuration reduces WAN bandwidth for small subnets while centralizing management for larger ones.

How does DNS caching affect troubleshooting?

DNS caching stores query results for the TTL specified in each record, reducing upstream query load but potentially serving stale data after record updates. When troubleshooting resolution failures, administrators must distinguish between cached and fresh responses. Flushing the cache with clear ip dns cache on Cisco routers or ipconfig /flushdns on Windows clients forces fresh lookups, revealing whether the issue lies in cached data or upstream servers. Negative caching stores NXDOMAIN responses, causing repeated failures for typos or recently added domains until the negative TTL expires. Understanding cache behavior prevents misdiagnosing authoritative server issues as client-side problems.

What is DHCP Option 82 and when is it used?

DHCP Option 82 (relay agent information) allows relay agents to insert circuit-id and remote-id sub-options into forwarded requests, identifying the client's physical location. Centralized DHCP servers use this information to assign addresses from location-specific pools, enforce policies, or log client activity. For example, a campus network might assign different DNS servers to dormitory residents versus faculty offices based on the relay agent's interface. Cisco IOS routers insert Option 82 automatically when relaying requests; the ip dhcp relay information option command enables this feature globally. DHCP snooping on switches also uses Option 82 to build binding tables, linking MAC addresses to switch ports for Dynamic ARP Inspection.

Why do some DNS queries use TCP instead of UDP?

DNS queries use UDP port 53 by default for speed and efficiency, as most responses fit within a single 512-byte UDP packet. However, TCP port 53 is required for zone transfers (AXFR and IXFR), which replicate entire DNS zones between primary and secondary nameservers. TCP is also used when a response exceeds 512 bytes, triggering the truncation (TC) bit in the UDP response and prompting the client to retry over TCP. DNSSEC responses often exceed 512 bytes due to cryptographic signatures, making TCP more common in DNSSEC-enabled environments. Firewalls that block TCP 53 break zone transfers and large responses, a frequent misconfiguration in enterprise networks.

How do I prevent DHCP starvation attacks?

DHCP starvation attacks flood a DHCP server with DHCPDISCOVER messages using spoofed MAC addresses, exhausting the address pool and denying service to legitimate clients. DHCP snooping on Cisco Catalyst switches mitigates this attack by rate-limiting DHCP messages on untrusted ports, typically to 10-15 packets per second. The ip dhcp snooping limit rate 15 command applied to access ports prevents a single device from consuming all available addresses. Additionally, enabling port security limits the number of MAC addresses per port, blocking attackers who spoof thousands of MACs. Monitoring show ip dhcp snooping statistics reveals abnormal request rates, enabling rapid response.

What is the difference between authoritative and recursive DNS servers?

Authoritative DNS servers store and serve records for specific domains, answering queries with definitive data from zone files. For example, Networkers Home's authoritative nameservers respond to queries for networkershome.com with A records pointing to our web server. Recursive DNS servers accept queries from clients and perform iterative lookups on their behalf, contacting root, TLD, and authoritative servers until they obtain an answer. ISPs and enterprises operate recursive resolvers; clients configure these resolvers in their network settings. A single server can perform both roles—serving authoritative data for local zones while recursively resolving external queries—but best practices separate these functions to isolate security risks and optimize performance.