DHCP & DNS — How Devices Get IPs and Resolve Names

What DHCP and DNS Are and Why They Matter in 2026

DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses, subnet masks, default gateways, and DNS server addresses to devices joining a network. DNS (Domain Name System) translates human-readable domain names like networkershome.com into machine-readable IP addresses like 103.21.58.242. Without DHCP, network administrators would manually configure every laptop, phone, and IoT device; without DNS, users would memorize numeric addresses for every website and service. Together, these protocols form the foundation of modern IP networking—DHCP handles address allocation, DNS handles name resolution, and both are tested extensively in Cisco's CCNA, CCNP, and CCIE certification tracks.

In 2026, DHCP and DNS remain critical as enterprises migrate to hybrid cloud architectures and zero-trust security models. Indian organizations—from Cisco India's Bengaluru campus to Akamai's edge nodes in Mumbai—rely on DHCP for dynamic endpoint provisioning and DNS for service discovery in Kubernetes clusters, SD-WAN overlays, and multi-cloud environments. Understanding these protocols is non-negotiable for network engineers: our 45,000+ placements at HCL, Aryaka, Barracuda, and Wipro consistently report that DHCP troubleshooting and DNS security (DNSSEC, DNS over HTTPS) appear in technical interviews and day-one production incidents.

This chapter walks through DHCP's four-way handshake, DNS query resolution, configuration on Cisco IOS routers and switches, common failure modes, and real-world deployment patterns observed in our HSR Layout lab and during our 4-month paid internship at the Network Security Operations Division. By the end, you will configure DHCP pools, interpret DNS packet captures, and answer the exact questions Cisco India hiring managers ask during L1/L2 network engineer interviews.

How DHCP Works Under the Hood—The DORA Process

DHCP operates as a client-server protocol using UDP ports 67 (server) and 68 (client). When a device boots without a configured IP address, it initiates a four-step exchange known as DORA: Discover, Offer, Request, Acknowledge. Each step uses broadcast or unicast frames depending on the client's current state, and the entire process typically completes in under 500 milliseconds on a local LAN.

Step 1: DHCP Discover (Broadcast)

The client sends a DHCPDISCOVER message as a Layer 2 broadcast (destination MAC FF:FF:FF:FF:FF:FF) and Layer 3 broadcast (destination IP 255.255.255.255, source IP 0.0.0.0). This frame reaches all devices on the local subnet. The discover message includes the client's MAC address and may include Option 55 (Parameter Request List) specifying which configuration parameters the client wants—subnet mask, default gateway, DNS servers, NTP servers, TFTP server for IP phones.

Step 2: DHCP Offer (Broadcast or Unicast)

One or more DHCP servers respond with a DHCPOFFER message containing an available IP address from their configured pool, lease duration (typically 24 hours to 7 days), subnet mask, default gateway, and DNS server addresses. If multiple DHCP servers exist on the network—common in enterprise environments for redundancy—the client receives multiple offers. The offer is usually broadcast to 255.255.255.255 because the client does not yet have an IP address, though RFC 2131 permits unicast if the client sets a flag requesting it.

Step 3: DHCP Request (Broadcast)

The client selects one offer (typically the first received) and broadcasts a DHCPREQUEST message to all DHCP servers, identifying the chosen server by its IP address in Option 54 (Server Identifier). This broadcast informs other servers that their offers were declined, allowing them to return those IP addresses to their available pools. The request is broadcast rather than unicast because the client still does not have a confirmed IP address.

Step 4: DHCP Acknowledge (Broadcast or Unicast)

The selected server responds with a DHCPACK message, confirming the IP address lease and delivering all requested configuration parameters. The client binds the IP address to its network interface, configures its TCP/IP stack with the provided gateway and DNS servers, and begins normal network communication. The lease timer starts; at 50 percent of the lease duration (T1 timer), the client attempts to renew directly with the original server via unicast DHCPREQUEST. At 87.5 percent (T2 timer), if renewal fails, the client broadcasts a renewal request to any available DHCP server.

In our HSR Layout lab, we captured DORA exchanges using Wireshark during CCNA training sessions and observed that Option 82 (DHCP Relay Agent Information) is inserted by Cisco switches when DHCP servers reside on different VLANs, enabling centralized IP address management across multi-building campuses—a configuration pattern used by Infosys and TCS in their Bengaluru development centers.

How DNS Works—Recursive and Iterative Query Resolution

DNS translates domain names into IP addresses through a hierarchical, distributed database. When a user types www.networkershome.com into a browser, the operating system's DNS resolver initiates a query that may traverse multiple DNS servers before returning the answer. DNS uses UDP port 53 for queries under 512 bytes and TCP port 53 for zone transfers (AXFR) and responses exceeding 512 bytes, though EDNS0 (Extension Mechanisms for DNS) allows larger UDP responses up to 4096 bytes.

Recursive Query Flow

A recursive query places the burden of resolution on the DNS server. The client's stub resolver sends a query to its configured DNS server (often provided via DHCP Option 6). If the server does not have the answer cached, it performs iterative queries on behalf of the client, starting at a root nameserver, then querying the .com TLD (Top-Level Domain) nameserver, then querying the authoritative nameserver for networkershome.com. The recursive server caches each intermediate answer according to its TTL (Time To Live) value, then returns the final A record (IPv4 address) or AAAA record (IPv6 address) to the client.

Iterative Query Flow

In an iterative query, the DNS server returns the best answer it currently has—either the final IP address or a referral to another nameserver. The client's resolver must then query the referred server. Iterative queries are used between DNS servers during recursive resolution; for example, a root nameserver responds to a query for networkershome.com with a referral to the .com TLD nameservers rather than performing the lookup itself.

DNS Record Types

DNS caching occurs at multiple layers: browser cache (typically 60 seconds), operating system resolver cache (managed by systemd-resolved on Linux or DNS Client service on Windows), and recursive DNS server cache (respecting each record's TTL). Cached answers reduce query latency and upstream load but can cause stale data if TTLs are set too high—a common issue when migrating services between data centers or switching CDN providers.

DHCP vs DNS vs Static IP Assignment—When to Use Each

DHCP, DNS, and static IP assignment serve complementary roles in network design. Choosing the wrong approach leads to operational overhead, security gaps, or service outages. This table compares the three methods across key decision criteria observed in production networks at Cisco India, Akamai, and our internship partner organizations.

In practice, enterprises use all three: DHCP for employee laptops and smartphones, static IPs for infrastructure (routers, firewalls, domain controllers), and DNS for service discovery and failover. DHCP reservations—binding a specific IP address to a MAC address—combine DHCP's automation with static IP's predictability, commonly used for IP phones, wireless access points, and network printers. Our CCNA course in Bangalore dedicates lab sessions to configuring DHCP pools with exclusions and reservations on Cisco IOS routers, mirroring real-world deployment patterns at HCL and Wipro.

Configuring DHCP and DNS on Cisco IOS Routers

Cisco routers and Layer 3 switches can function as DHCP servers, DHCP relay agents (IP helpers), and DNS forwarders. The following configurations demonstrate common enterprise scenarios tested in CCNA and CCNP exams and deployed in production networks across India.

Basic DHCP Server Configuration

Router(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.10
Router(config)# ip dhcp pool VLAN10_POOL
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)# lease 7
Router(dhcp-config)# exit

This configuration creates a DHCP pool named VLAN10_POOL serving the 192.168.10.0/24 subnet. The ip dhcp excluded-address command reserves 192.168.10.1 through 192.168.10.10 for static assignment to infrastructure devices. The pool assigns Google's public DNS servers (8.8.8.8 and 8.8.4.4) and sets a 7-day lease duration. Clients receive IP addresses from 192.168.10.11 through 192.168.10.254.

DHCP Relay Agent (IP Helper) Configuration

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

When the DHCP server resides on a different subnet, routers must relay DHCP broadcasts. The ip helper-address command on the client-facing interface converts DHCP broadcasts to unicast and forwards them to the centralized DHCP server at 10.1.1.100. The relay agent inserts Option 82 (giaddr field) containing the interface IP address, enabling the DHCP server to select the correct pool based on the client's subnet. This configuration is standard in multi-VLAN campus networks at Infosys, TCS, and IBM India.

DNS Forwarder Configuration

Router(config)# ip dns server
Router(config)# ip name-server 8.8.8.8
Router(config)# ip name-server 1.1.1.1
Router(config)# ip domain-lookup

The ip dns server command enables the router to act as a DNS proxy, forwarding client queries to upstream nameservers (8.8.8.8 and 1.1.1.1) and caching responses. This reduces WAN bandwidth consumption in branch offices and improves query response times. The router's DNS cache is visible via show hosts. For security, disable DNS lookups on CLI typos with no ip domain-lookup in production environments to prevent accidental DNS queries when mistyping commands.

Verifying DHCP and DNS Operation

Router# show ip dhcp binding
Router# show ip dhcp pool VLAN10_POOL
Router# show ip dhcp conflict
Router# show hosts
Router# debug ip dhcp server events

The show ip dhcp binding command displays active leases with client MAC addresses, assigned IPs, and lease expiration times. The show ip dhcp conflict command reveals IP addresses that triggered gratuitous ARP conflicts, indicating duplicate static IPs or rogue DHCP servers. During troubleshooting in our HSR Layout lab, we use debug ip dhcp server events to capture real-time DORA message exchanges, a technique that resolved a subnet exhaustion issue during a recent batch's capstone project.

Common DHCP and DNS Pitfalls and Interview Gotchas

DHCP and DNS failures account for a significant percentage of network trouble tickets at our internship partner organizations. Cisco India and Akamai technical interviewers probe candidates' troubleshooting methodology by presenting scenarios involving these protocols. The following pitfalls appear repeatedly in production incidents and CCIE lab exams.

DHCP Scope Exhaustion

When all IP addresses in a DHCP pool are leased, new clients receive no offer and fail to join the network. This occurs in undersized pools (e.g., /28 subnet for 20 devices) or when lease durations are excessively long (30+ days) and devices churn frequently. The solution is to expand the subnet, reduce lease duration to 24-48 hours, or implement DHCP snooping to detect and block rogue clients. In a recent incident at an Aryaka customer site, we discovered 200+ stale leases from decommissioned IoT sensors; clearing the bindings with clear ip dhcp binding * immediately restored service.

Rogue DHCP Server

An unauthorized DHCP server—often a misconfigured home router or malicious device—responds to discover messages faster than the legitimate server, assigning incorrect gateway or DNS addresses. Clients lose internet connectivity or are redirected to phishing sites. DHCP snooping on Cisco switches mitigates this attack by designating trusted ports (uplinks to legitimate DHCP servers) and untrusted ports (access ports to end devices), dropping DHCP offers from untrusted sources. Configuration example:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20,30
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# exit

DNS Cache Poisoning

An attacker injects false DNS records into a resolver's cache, redirecting users to malicious IP addresses. Kaminsky's 2008 attack exploited predictable transaction IDs and source ports; modern resolvers randomize both and validate responses against the query. DNSSEC (DNS Security Extensions) cryptographically signs DNS records, preventing tampering, but adoption remains low—only 30 percent of .com domains support DNSSEC as of 2026. Organizations handling sensitive data (banks, healthcare) should enforce DNSSEC validation on recursive resolvers and deploy DNS over HTTPS (DoH) or DNS over TLS (DoT) to encrypt queries between clients and resolvers, preventing ISP-level interception.

Split-Horizon DNS Misconfiguration

Split-horizon DNS serves different answers for internal versus external queries—internal clients resolve mail.company.com to a private IP (10.1.1.50), external clients resolve it to a public IP (203.0.113.50). Misconfiguration causes internal users to route through the firewall's public interface, consuming NAT resources and increasing latency. The fix is to maintain separate internal and external DNS zones and ensure internal resolvers query the internal authoritative server. This pattern is standard at Cisco India's Bengaluru office, where internal services use RFC 1918 addresses and external services use provider-assigned public IPs.

TTL Tuning for Service Migrations

When migrating a service between data centers or cloud providers, administrators reduce DNS TTLs to 60-300 seconds days in advance, allowing rapid cutover. Forgetting to reduce TTLs results in clients caching the old IP for hours or days post-migration, causing partial outages. After migration, TTLs should be restored to 3600-86400 seconds to reduce query load. During our 4-month paid internship, a trainee successfully migrated a customer's web application from AWS Mumbai to Azure Pune by lowering TTLs 48 hours prior, performing the cutover during a maintenance window, and monitoring query patterns via Cloudflare Analytics—a procedure now documented in our internship playbook.

Real-World DHCP and DNS Deployment Scenarios in Indian Enterprises

DHCP and DNS configurations vary by organization size, security posture, and regulatory requirements. The following scenarios reflect deployment patterns observed at our 800+ hiring partners, including Cisco India, HCL, Akamai, Barracuda, Movate, and Accenture.

Campus Network with Centralized DHCP

A 5,000-employee IT services company in Bengaluru operates a three-building campus with 20 VLANs. Two redundant Windows Server DHCP servers in the data center serve all VLANs via IP helper addresses configured on distribution layer Cisco Catalyst 9300 switches. DHCP failover is configured in load-balance mode, splitting the address pool 50/50 between servers. Each VLAN has a /23 subnet (510 usable addresses) with 48-hour lease duration. DHCP snooping is enabled on all access switches, and Option 82 insertion allows the DHCP servers to log which switch port each client connects to, aiding incident response. DNS is provided by on-premises Active Directory domain controllers with conditional forwarders to Cloudflare (1.1.1.1) for internet queries.

Branch Office with Local DHCP and DNS Caching

A retail chain with 200 stores across India deploys Cisco ISR 4000 series routers at each branch. The router acts as DHCP server for point-of-sale terminals, employee laptops, and IP cameras, and as a DNS forwarder caching queries to reduce WAN bandwidth. DHCP pools are sized for 50 devices per store with 24-hour leases. The router's DNS cache is pre-populated with frequently accessed internal domains (inventory.company.com, payroll.company.com) via static host entries, reducing query latency during peak hours. SD-WAN policies prioritize DNS and DHCP traffic to ensure rapid device onboarding even during WAN congestion.

Cloud-Native Deployment with DHCP Relay to AWS

A fintech startup in Hyderabad runs its infrastructure on AWS. VPCs use AWS-provided DHCP option sets for EC2 instances, but on-premises offices relay DHCP requests to an EC2-based DHCP server via Site-to-Site VPN. This centralizes IP address management and allows the DHCP server to push custom options like NTP servers (pointing to AWS Time Sync Service) and internal DNS resolvers (Amazon Route 53 Resolver endpoints). DNS queries from on-premises offices are forwarded to Route 53 Resolver over the VPN, enabling seamless resolution of both public internet domains and private hosted zones (internal.company.local).

Zero-Trust Architecture with DHCP Fingerprinting

A cybersecurity-conscious enterprise in Pune implements DHCP fingerprinting to identify device types based on Option 55 parameter request lists. Cisco ISE (Identity Services Engine) integrates with DHCP logs to profile devices—Windows laptops request options 1,3,6,15,31,33, while iPhones request 1,3,6,15,119,252. ISE assigns devices to VLANs based on fingerprint and user identity, enforcing micro-segmentation. DNS queries are logged and analyzed by Cisco Umbrella (cloud-delivered DNS security) to detect malware command-and-control traffic, cryptomining, and data exfiltration attempts. This architecture aligns with RBI's cybersecurity guidelines for financial institutions and is a reference design taught in our CCNA and CCNP Security courses.

How DHCP and DNS Map to CCNA, CCNP, and CCIE Certification Syllabi

DHCP and DNS are foundational topics across Cisco's certification tracks. Mastery is required not only for passing exams but for day-one job readiness at Cisco India, HCL, Aryaka, and other hiring partners. The following table maps protocol concepts to exam blueprints and typical interview questions.

Cisco India's technical interviews for L2/L3 network engineer roles (₹4-8 LPA) typically include a whiteboard exercise: "Draw the DORA process and explain what happens if the DHCPREQUEST is lost." CCIE-level interviews (₹15-25 LPA) probe deeper: "How would you design DHCP for a multi-region SD-WAN deployment with 500 branches, ensuring sub-second failover and centralized logging?" Our Networking Fundamentals course and hands-on labs in our HSR Layout facility prepare candidates for both question types, with 24×7 rack access to practice configurations on Cisco Catalyst, Nexus, and ASR platforms.

Frequently Asked Questions About DHCP and DNS

What happens if a DHCP server is unavailable when a client's lease expires?

The client attempts to renew at T1 (50 percent of lease duration) via unicast to the original server. If the server is unreachable, the client retries at T2 (87.5 percent) by broadcasting a renewal request to any available DHCP server. If no server responds by lease expiration, the client releases the IP address and returns to the DHCPDISCOVER state, losing network connectivity until a server becomes available. To prevent this, enterprises deploy redundant DHCP servers with failover or load-balancing configurations, ensuring at least one server is always reachable.

Can a router be both a DHCP server and a DHCP relay agent simultaneously?

Yes, but for different subnets. A Cisco router can serve DHCP to locally connected VLANs while relaying requests from other VLANs to a centralized DHCP server. For example, a branch office router might serve DHCP to the guest Wi-Fi VLAN (192.168.100.0/24) while relaying requests from the employee VLAN (10.10.10.0/24) to the data center DHCP server. The router's interface configuration determines behavior: interfaces with ip helper-address relay, interfaces with local DHCP pools serve.

Why do DNS queries sometimes use TCP instead of UDP?

DNS uses UDP port 53 for standard queries because UDP's low overhead suits the request-response pattern. However, DNS switches to TCP port 53 in three scenarios: (1) responses exceeding 512 bytes (though EDNS0 allows larger UDP responses), (2) zone transfers (AXFR and IXFR) between primary and secondary nameservers, and (3) when the UDP response has the TC (truncated) flag set, signaling the client to retry over TCP. DNS over TLS (DoT) and DNS over HTTPS (DoH) always use TCP for encryption.

What is DHCP Option 82 and when is it used?

DHCP Option 82 (Relay Agent Information) is inserted by DHCP relay agents—typically Layer 3 switches or routers—to provide the DHCP server with information about the client's physical location. Sub-options include Circuit ID (switch port identifier) and Remote ID (switch MAC address). This enables the DHCP server to assign IP addresses based on switch port, enforce per-port address limits, and log which port each client connects to for security auditing. Option 82 is standard in enterprise campus networks and is required for Cisco ISE profiling and dynamic VLAN assignment.

How does DNSSEC prevent DNS spoofing?

DNSSEC adds cryptographic signatures to DNS records using public-key cryptography. When a DNSSEC-enabled resolver queries a signed zone, it receives both the DNS answer and a digital signature (RRSIG record). The resolver validates the signature using the zone's public key (published in a DNSKEY record) and verifies the chain of trust up to the root zone. If the signature is invalid or missing, the resolver rejects the answer, preventing attackers from injecting false records. DNSSEC does not encrypt queries—it only authenticates responses. For privacy, combine DNSSEC with DNS over HTTPS (DoH) or DNS over TLS (DoT).

What is the difference between a DNS forwarder and a DNS resolver?

A DNS resolver (also called a recursive resolver) performs the full iterative query process on behalf of clients, starting at root nameservers and traversing the DNS hierarchy until it obtains the authoritative answer. A DNS forwarder simply forwards client queries to an upstream resolver (e.g., 8.8.8.8) and caches the responses. Forwarders reduce configuration complexity and WAN bandwidth in branch offices but rely on the upstream resolver's availability and trustworthiness. Cisco routers configured with ip dns server and ip name-server act as forwarders, not full resolvers.

How do I troubleshoot a client that receives an IP address but cannot access the internet?

Verify the DHCP-assigned default gateway with ipconfig /all (Windows) or ip route show (Linux). Ping the gateway; if unreachable, check VLAN configuration and switch port assignment. If the gateway responds, ping an external IP (8.8.8.8); failure indicates a routing or firewall issue. If external IPs are reachable but domain names fail, verify DNS server addresses from DHCP and test resolution with nslookup google.com. If DNS queries time out, check firewall rules blocking UDP/TCP port 53 or verify the DNS server is operational. This troubleshooting flow is practiced extensively in our HSR Layout lab during CCNA training, mirroring real-world incident response at Cisco India and Akamai.

What are the security risks of using public DNS servers like 8.8.8.8?

Public DNS servers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) offer high availability and fast resolution but introduce privacy and compliance risks. DNS queries reveal browsing behavior; Google and Cloudflare log queries for analytics and threat intelligence. For organizations subject to DPDP Act 2023 (India's data protection law) or RBI guidelines, routing DNS queries to foreign servers may violate data localization requirements. Additionally, public DNS servers cannot resolve internal private domains (company.local). Best practice: use internal DNS servers for corporate devices, configure conditional forwarders to public resolvers only for internet domains, and enforce DNS over HTTPS (DoH) to prevent ISP-level query interception.