DHCP DNS NTP Network Services Lab
DHCP DNS NTP Network Services Lab
Introduction
Network services like DHCP, DNS, and NTP are the backbone of any functioning enterprise network. Without these services, hosts cannot automatically receive IP addresses, users cannot resolve domain names to reach websites, and devices cannot maintain synchronized clocks for logging and security. In the CCNA exam blueprint, network services fall under the Network Fundamentals domain, which carries a 20% weight on the exam, making this a critical area to master.
In this lesson, you will learn what each of these three services does, how they operate within an enterprise network topology, and how they interact with both IPv4 and IPv6 environments. By the end, you will understand how DNS and NTP fit into a real provider-connected network, how DHCP delivers addressing to clients, and how newer mechanisms like DHCP Option 108 and DNS64 extend these services into IPv6-only and dual-stack deployments.
Key Concepts
Before diving into configurations, let us establish what each service does and why it matters.
DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addressing information to hosts on a network. Instead of manually configuring every workstation with an IP address, subnet mask, default gateway, and DNS server, DHCP handles this dynamically. This reduces administrative overhead and eliminates configuration errors.
DNS (Domain Name System) translates human-readable domain names into IP addresses. When a user types a URL into a browser, DNS resolves that name to the correct IP address so the connection can be established. In an enterprise network, DNS servers are deployed both internally and externally to handle name resolution for private and public resources.
NTP (Network Time Protocol) synchronizes clocks across all network devices. Accurate time is essential for correlating log entries, validating security certificates, and ensuring authentication protocols function correctly. Even a few seconds of clock drift between devices can cause significant operational issues.
The following table summarizes how these three services compare:
| Service | Purpose | Transport | Why It Matters |
|---|---|---|---|
| DHCP | Automatic IP address assignment | UDP | Eliminates manual host configuration |
| DNS | Name-to-address resolution | UDP/TCP | Enables users to reach resources by name |
| NTP | Clock synchronization | UDP | Ensures accurate timestamps for logs and security |
In a typical enterprise topology, your network (with its own ASN, or Autonomous System Number) connects to upstream providers. Each provider operates its own ASN and is responsible for forwarding data through its portion of the path. DNS and NTP servers sit within your enterprise network, serving internal clients, while also communicating with external DNS roots and NTP sources across provider boundaries.
How It Works
DNS in an Enterprise Network
Consider an enterprise network with ASN 65000 that connects to multiple upstream providers (for example, providers with ASN 701, ASN 3356, ASN 10796, and ASN 16509). When a host inside your network needs to reach an external resource like a website hosted by another company with ASN 65512, the process relies on DNS at every step.
Your internal DNS server receives a query from the client. If the DNS server does not have the answer cached, it queries external DNS servers across the provider network. Each AS along the path is responsible for delivering data to the other side. The response flows back through the provider chain, and your DNS server caches the result and returns the IP address to the client.
NTP Synchronization
NTP works in a hierarchical model. Your enterprise NTP server synchronizes with upstream time sources, and all internal devices then synchronize their clocks against your enterprise NTP server. In the same topology where your ASN 65000 network connects through multiple providers, NTP traffic traverses those provider connections to reach authoritative time sources. Internally, routers, switches, and servers all point to the local NTP server so that every device in the network shares a consistent time reference.
DHCP and IPv6-Only Networks
In traditional IPv4 networks, DHCP (DHCPv4) assigns addresses, gateways, and DNS server information to clients. However, as networks transition toward IPv6, new mechanisms come into play.
DHCP Option 108 (defined in RFC 8925) is the IPv6-Only Preferred option for DHCPv4. When a DHCPv4 server includes Option 108 in its response, it signals to capable clients that they should operate using IPv6 only, if possible. This allows a gradual transition where the network can tell modern hosts to prefer IPv6 while legacy devices that do not understand Option 108 simply ignore it and continue using IPv4.
DNS64 and NAT64
In IPv6-only network segments, hosts have no IPv4 address and cannot directly reach IPv4-only resources on the internet. Two companion technologies solve this:
- DNS64 servers synthesize AAAA (IPv6) records for destinations that only have A (IPv4) records. When an IPv6-only client queries for a hostname that only has an IPv4 address, the DNS64 server constructs an IPv6 address by embedding the IPv4 address within a special NAT64 prefix.
- NAT64 routers translate between IPv6 and IPv4, allowing the IPv6-only client to reach the IPv4-only destination.
The NAT64 prefix must be advertised into the network so that IPv6-only hosts know how to route traffic toward the NAT64 translator.
There are three placement models for NAT64 and DNS64 in an enterprise:
| Placement | NAT64 Location | DNS64 Scope | Use Case |
|---|---|---|---|
| Service Block | Near IPv4-only resources | NAT64 prefix advertised to network | Protecting legacy IPv4 resources |
| Integrated | Near IPv6-only users | DNS64 limited to specific source addresses; NAT64 prefix resides with default route | IPv6-only user segments reaching IPv4 resources |
| Edge | At the internet boundary | Full internal IPv6 for everything | Only needed for external sites that have not adopted dual stack |
In the edge placement model, IPv6 is fully functional internally. IPv6-only users can reach both internal IPv6-only and dual-stack resources directly. NAT64 is only required for external internet sites that have not yet enabled IPv6.
Discovering the NAT64 Prefix
Hosts in an IPv6-only network need to learn the NAT64 prefix. Two mechanisms support this:
- RFC 7050 / RFC 8880: The host queries the special domain name
ipv4only.arpavia DNS64. The synthesized AAAA response reveals the NAT64 prefix in use. You can also host an authoritative DNS zone foripv4only.arpawith an AAAA record locally to reduce load on external DNS servers. - RFC 8781: The NAT64 prefix is advertised directly in Router Advertisements (RA) using the PREF64 option, so hosts learn the prefix without needing a DNS query.
Important: Hosts must support RFC 8880 or RFC 8781, along with RFC 8925 (DHCP Option 108), to function correctly on an IPv6-only network segment.
Configuration Example
IPv6-Only (IPv6-Mostly) VLAN Configuration
When deploying an IPv6-mostly network, you configure the VLAN interface to support IPv6 while enabling flow monitoring to track traffic patterns. The reference material shows a configuration for an IPv6-only VLAN:
show run interface vlan150
interface Vlan150
ip flow monitor FLOWMONITOR-INGRESS input
ip flow monitor FLOWMONITOR-EGRESS output
This configuration applies NetFlow monitoring on VLAN 150 in both directions. The ingress monitor captures traffic entering the interface, while the egress monitor captures traffic leaving it. Flow monitoring is essential during an IPv6 transition because it allows you to observe what protocols and addresses are actually being utilized on the network, helping you confirm that IPv6 traffic is flowing as expected.
Verifying IPv6-Only Client Connectivity
On a Windows client connected to an IPv6-only VLAN, you can verify the addressing with ipconfig:
C:\>ipconfig
Windows IP Configuration
Ethernet adapter Ethernet0:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:db8:8000:150::2
Link-local IPv6 Address . . . . . : fe80::9c73:7c11:8a59:3f3d%13
Autoconfiguration IPv4 Address. . : 169.254.42.133
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 2001:db8:8000:150::1
fe80::272:78ff:fe55:17d%13
Notice several key details in this output:
- The host has a valid global IPv6 address (2001:db8:8000:150::2) and a link-local address
- The default gateway is an IPv6 address (2001:db8:8000:150::1), confirming IPv6 routing is active
- The IPv4 address is an autoconfiguration address (169.254.x.x), meaning no DHCPv4 server provided an IPv4 address -- this is expected behavior on an IPv6-only VLAN
- There is no support for IPv4 literals on this segment, so all connectivity relies on IPv6 and DNS64/NAT64 for reaching IPv4-only destinations
Transition Strategy
When rolling out IPv6-only across an enterprise, the recommended approach from the reference material is:
- Start from the outside in -- begin with network engineers and help desk staff who can troubleshoot issues
- Migrate VLAN by VLAN, then site by site
- Address the data center and network infrastructure as separate phases
- Select specific user VLANs for initial deployment before expanding
Best Practice: Use NetFlow monitoring on each VLAN to verify traffic patterns before and after enabling IPv6-only mode. This data-driven approach ensures you can identify any applications or services that still depend on IPv4.
Real-World Application
In production enterprise networks, DHCP, DNS, and NTP are among the first services deployed and the last to be decommissioned. Every device on the network depends on at least one of them.
DNS and NTP in multi-provider environments: When your enterprise connects to multiple upstream providers (each with their own ASN), DNS and NTP traffic traverses these provider links. Redundancy is critical -- if your primary provider path fails, DNS and NTP must still function through an alternate provider. This is why enterprises typically deploy multiple DNS and NTP servers and ensure they are reachable through diverse network paths.
IPv6 transition planning: As organizations move toward IPv6-only networks, the interplay between DHCPv4 Option 108, DNS64, and NAT64 becomes essential. Modern enterprise deployments use the IPv6-mostly approach, where DHCP Option 108 tells capable clients to prefer IPv6, DNS64 synthesizes IPv6 addresses for IPv4-only destinations, and NAT64 translates the actual traffic. This allows a phased migration without breaking connectivity for legacy applications.
Flow monitoring during transitions: Deploying NetFlow monitors on VLAN interfaces provides visibility into what traffic is using IPv4 versus IPv6. This data helps network engineers make informed decisions about when a VLAN is ready to go fully IPv6-only.
Summary
- DHCP, DNS, and NTP are foundational network services that every enterprise must deploy reliably; they fall within the CCNA Network Fundamentals domain, which represents 20% of the exam.
- In a multi-provider enterprise topology, DNS and NTP traffic flows across AS boundaries, with each provider responsible for forwarding data through its segment of the path.
- DHCP Option 108 (RFC 8925) enables IPv6-only preferred signaling, telling capable clients to use IPv6 instead of requesting an IPv4 address via DHCPv4.
- DNS64 and NAT64 work together to allow IPv6-only hosts to reach IPv4-only destinations, with three deployment models: service block, integrated, and edge placement.
- When transitioning to IPv6-only, deploy VLAN by VLAN with NetFlow monitoring to validate traffic patterns before expanding to additional segments.
In the next lesson, we will build on these services by exploring how routing protocols interact with IPv4 and IPv6 dual-stack environments, putting the network services you learned here into a broader context.