DHCP, DNS, SLAAC, and time protocols can all appear in one troubleshooting scenario because a client may depend on each of them before an application works. They still solve different problems.
Dynamic Host Configuration Protocol (DHCP) provides configuration to clients. Stateless Address Autoconfiguration (SLAAC) lets an IPv6 host form an address from router-advertised information. Domain Name System (DNS) resolves names and publishes other domain data. Network Time Protocol (NTP) and Precision Time Protocol (PTP) synchronize clocks.
Fast rule: Address problem? Start with DHCP or SLAAC. Name problem? Start with DNS. Timeline or clock problem? Start with the time service. Do not change one service to fix a different dependency.
1. Network service jobs at a glance
| Service or feature | Primary job | Strong clue | Does not do by itself |
|---|---|---|---|
| DHCP | Provide IP configuration to clients | Scope, lease, reservation, option, relay, exclusion | Resolve hostnames |
| SLAAC | Let an IPv6 host form an address from router-advertised prefix information | IPv6 host configures itself from a router advertisement | Publish DNS records |
| DNS | Resolve names and publish domain data | A, AAAA, CNAME, MX, TXT, NS, PTR, resolver, zone | Assign the client an IP address |
| NTP | Synchronize ordinary network clocks | Logs, authentication, servers, network devices, enterprise time | Provide high-precision local timing for specialized systems |
| PTP | Provide tighter clock synchronization where high precision matters | Industrial, financial, media, measurement, hardware timestamping | Secure an NTP exchange |
| NTS | Add cryptographic security to NTP client-server synchronization | Protected or authenticated NTP time | NTP time synchronization itself |
2. DHCP scope decisions: reservation, exclusion, lease, and options
A DHCP scope or pool defines the addresses and configuration available to clients on a subnet. Several settings inside that scope are easy to confuse.
| Setting | What it does | Question clue |
|---|---|---|
| Scope or pool | Defines the address range and subnet-related configuration available for leasing | Which addresses can clients receive? |
| Reservation | Associates a client identifier with a predictable leased address | This DHCP client should receive the same address each time |
| Exclusion | Keeps selected addresses out of dynamic allocation | Do not lease these addresses to ordinary clients |
| Lease time | Controls how long a client may keep an assignment before renewal | High client turnover or address-pool pressure |
| Options | Provide settings such as default gateway and DNS server addresses | The client has an address but received the wrong gateway or resolver |
A reservation is still DHCP. The client requests configuration and the server gives it the reserved address when the identifying information matches.
An exclusion is not an assignment. It prevents the server from leasing an address from the dynamic pool. A printer using a manually configured address may need that address excluded from a pool, but the exclusion itself does not configure the printer.
Lease time is a capacity and operational decision. Shorter leases return addresses to the pool sooner when clients come and go, but they create more renewal activity. Longer leases reduce renewal frequency but keep addresses committed longer.
A valid leased address does not prove the rest of the configuration is correct. A bad default-gateway option can break off-subnet connectivity. A bad DNS option can make hostname access fail while direct IP access still works.
3. DHCP exchange and relay: local broadcasts need help across routers
A typical initial IPv4 DHCP exchange follows this sequence:
- The client sends a DHCPDISCOVER to find available DHCP service.
- A server replies with a DHCPOFFER.
- The client sends a DHCPREQUEST for the selected offer.
- The server confirms the lease with a DHCPACK.
The first client messages occur before the client has complete network configuration. That makes local broadcast behavior important.
Routers do not ordinarily forward a client's local broadcast into another IP subnet. A DHCP relay, often configured as an IP helper, receives the client request on one subnet and forwards it toward a DHCP server on another. The relay also gives the server information it can use to select the appropriate scope.
That creates a useful troubleshooting split:
- Clients on the server's local subnet work, but clients on one remote VLAN fail: check the relay, VLAN interface, scope, and security path.
- Clients on every subnet fail: the server or a shared dependency deserves more attention.
- One client fails while neighbors work: start with that client, its port or VLAN, and its local configuration.
An Automatic Private IP Addressing (APIPA) address in 169.254.0.0/16 suggests that an IPv4 host did not obtain its expected DHCP lease. It does not tell you whether the server, scope, relay, VLAN, security rule, or client caused the failure.
Exam clue: If DHCP works on the server's subnet but not across a routed boundary, a missing or incorrect relay is a stronger first suspect than DNS.
4. SLAAC: IPv6 address formation from router advertisements
Stateless Address Autoconfiguration (SLAAC) lets an IPv6 host create an address using prefix and configuration information advertised by a router. The router advertisement tells the host about the local IPv6 prefix and related behavior. The host forms its own interface identifier rather than receiving one leased IPv6 address from a stateful address pool.
That distinction matters:
- DHCP scope question: a server or relay provides client configuration from managed address information.
- SLAAC question: the IPv6 host forms an address from router-advertised information.
- DNS question: the host already needs name-resolution data, regardless of how its IP address was formed.
SLAAC does not mean "IPv6 has no servers" or "IPv6 never uses other configuration services." It describes how the host can configure its IPv6 address without a server assigning that individual address.
When SLAAC fails, inspect whether the host receives the expected router advertisements, whether the prefix is correct, whether the interface is on the intended network, and whether local filtering interferes with required IPv6 control traffic.
Use the IPv6 Addressing and Prefix Reference when the real problem is address scope, prefix interpretation, compression, or local-versus-routed IPv6 behavior.
5. DNS record types: match the record to the question
| Record | Primary use | Fast clue |
|---|---|---|
| A | Map a name to an IPv4 address | IPv4 address for a hostname |
| AAAA | Map a name to an IPv6 address | IPv6 address for a hostname |
| CNAME | Make one name an alias of another canonical hostname | Friendly alias points to another name |
| MX | Identify mail exchangers and preference | Where mail for the domain should be delivered |
| TXT | Publish text used by verification, policy, and applications | Domain verification or email-policy text |
| NS | Identify authoritative name servers for a zone or delegation | Which servers are authoritative? |
| PTR | Map an address back to a name in reverse DNS | Reverse lookup from IP address to hostname |
The question usually tells you the direction of the lookup.
- Name to IPv4 address: A
- Name to IPv6 address: AAAA
- Address to name: PTR
- Alias to another hostname: CNAME
- Mail destination: MX
- Authoritative server: NS
- Text-based verification or policy: TXT
A CNAME points to another name, not directly to an IP address. The canonical name must then resolve through the appropriate address record.
6. DNS zones and roles: authority and recursion answer different questions
A forward zone organizes records used when starting from a name. A reverse zone supports address-to-name lookups through PTR records.
Server-role terms describe different properties:
- An authoritative server answers from zone data for which it has authority.
- A non-authoritative answer may come from cached or recursively obtained data.
- A recursive resolver accepts a client query and obtains the needed answer on the client's behalf.
- A primary server is the traditional writable source for authoritative zone data.
- A secondary server obtains a copy of the zone and can still answer authoritatively for it.
Do not treat secondary as another word for non-authoritative. A secondary server can hold an authoritative copy of the zone.
Do not treat recursive as another word for primary. Recursion describes how a resolver obtains answers for clients. Primary and secondary describe how authoritative zone data is maintained.
A local hosts file is another source of name mappings. If one workstation resolves a name differently from every other client, check its hosts file, resolver settings, and cache before changing the organization's authoritative DNS records.
7. DNSSEC, DoH, and DoT protect different parts of DNS
These names sound related because all three improve DNS security. The protection is different.
Domain Name System Security Extensions (DNSSEC) lets a validating resolver verify the origin and integrity of signed DNS data through a chain of trust. DNSSEC helps detect forged or altered signed DNS answers. It does not encrypt the query.
DNS over HTTPS (DoH) carries DNS queries through Hypertext Transfer Protocol Secure (HTTPS). DNS over Transport Layer Security (DoT) carries DNS over a Transport Layer Security (TLS) protected connection. Both protect the DNS transport between participating endpoints from ordinary observation or modification on that leg.
| Mechanism | Protects | Does not prove by itself |
|---|---|---|
| DNSSEC | Authenticity and integrity of signed DNS data | That the query path is encrypted |
| DoH | DNS transport inside HTTPS | That unsigned DNS data is authentic |
| DoT | DNS transport through TLS | That unsigned DNS data is authentic |
If the requirement says validate signed DNS answers, think DNSSEC.
If the requirement says encrypt DNS traffic between the client and resolver, think DoH or DoT.
8. NTP, PTP, and NTS: precision and protection are separate decisions
Clock synchronization affects log correlation, authentication, certificate validation, monitoring, scheduled work, and distributed systems.
Network Time Protocol (NTP) is the ordinary fit for synchronizing servers, network devices, and enterprise systems. It uses a hierarchy of time sources so systems can maintain a consistent clock.
Precision Time Protocol (PTP) is designed for environments that need much tighter synchronization. Specialized deployments may use hardware timestamping and carefully controlled local network paths. Industrial control, measurement, financial, and media systems are common clues.
Network Time Security (NTS) adds cryptographic protection to NTP client-server synchronization. NTS is about protecting the NTP exchange. It is not the higher-precision alternative to NTP.
Fast split: Ordinary clock synchronization points to NTP. Very high precision points to PTP. Cryptographically protected NTP points to NTS.
A time problem can look like a security or application problem. If logs disagree about event order, certificate checks fail unexpectedly, or authentication systems report time-sensitive errors, verify the clocks and configured time sources before rebuilding unrelated services.
9. Symptoms and useful evidence
| Symptom | Likely area | Useful evidence |
|---|---|---|
| One VLAN receives APIPA addresses while another gets leases | DHCP relay, scope, VLAN path, or security rule | Client config, relay setting, scope capacity, DHCP packet exchange |
| Client gets an address but the wrong gateway | DHCP option | Lease details and server option configuration |
| Direct IP access works, hostname access fails | DNS | Resolver setting, dig or nslookup result, DNS record, local hosts file |
| Reverse lookup fails while forward lookup works | Reverse zone or PTR record | PTR query and reverse-zone data |
| Only one client resolves a hostname to an unexpected address | Local cache, hosts file, or resolver configuration | Hosts file, configured resolver, cache, direct query to expected DNS server |
| IPv6 host is not forming an expected address | SLAAC and router advertisements | Router-advertisement reception, prefix, interface and VLAN placement |
| Logs show the same event in the wrong order across devices | Time synchronization | Clock offset, time source, reachability, synchronization status |
10. Scenario comparisons
A printer should keep one predictable address but still use DHCP
Use a DHCP reservation. Do not replace it with an exclusion. An exclusion only prevents ordinary dynamic allocation of an address.
A new VLAN cannot obtain leases, but a statically addressed test client can route to the DHCP server
Check the DHCP relay or IP helper and the scope for that VLAN. The fact that ordinary routed traffic works does not make the client's initial local broadcast cross the router.
An IPv6-only sensor should create its own address from the prefix announced on the LAN
Use SLAAC. The clue is host-generated IPv6 addressing based on router-advertised information.
Users can reach a web server by IP address but not by hostname
Test DNS before changing routes or DHCP addressing. Confirm the client's resolver, query result, expected record, and local hosts file.
A company wants clients to verify that signed DNS answers were not altered
Use DNSSEC validation. DoH or DoT can protect transport, but encrypted transport alone does not validate signed DNS data.
A plant control network requires much tighter clock synchronization than ordinary office systems
Use PTP when the design and equipment support the required precision. NTS solves a different problem by securing NTP.
11. Common exam traps
- Choosing an exclusion when the requirement is a predictable DHCP address. Use a reservation.
- Treating a reservation as a static address configured manually on the endpoint.
- Assuming a valid DHCP address proves the gateway and DNS options are correct.
- Blaming DNS when a client never obtained usable network configuration.
- Treating SLAAC as a DNS service.
- Using CNAME when the question asks for an IP address record.
- Using PTR for forward name-to-address resolution.
- Assuming a secondary DNS server is non-authoritative.
- Treating DNSSEC as DNS encryption.
- Treating DoH or DoT as proof that DNS data is authentic.
- Choosing PTP because the question says "secure time." Precision and cryptographic protection are different requirements.
- Rebuilding application services when the real problem is clock drift across devices.
12. Rapid review grid
| Need | Best fit |
|---|---|
| Give ordinary clients IPv4 configuration | DHCP |
| Same DHCP-managed address for one known client | Reservation |
| Keep addresses out of dynamic allocation | Exclusion |
| Forward DHCP requests across a routed boundary | DHCP relay or IP helper |
| IPv6 host forms an address from router-advertised prefix information | SLAAC |
| Hostname to IPv4 address | A record |
| Hostname to IPv6 address | AAAA record |
| IP address to hostname | PTR record in reverse DNS |
| Alias one hostname to another | CNAME |
| Validate signed DNS data | DNSSEC |
| Encrypt DNS transport | DoH or DoT |
| Ordinary enterprise clock synchronization | NTP |
| High-precision clock synchronization | PTP |
| Cryptographically protected NTP synchronization | NTS |
13. Official references
- CompTIA Network+ certification page
- RFC 2131: Dynamic Host Configuration Protocol
- RFC 1542: BOOTP Relay Agent Behavior
- RFC 4862: IPv6 Stateless Address Autoconfiguration
- RFC 1034: Domain Names - Concepts and Facilities
- RFC 4033: DNS Security Introduction and Requirements
- RFC 8484: DNS Queries over HTTPS
- RFC 7858: DNS over Transport Layer Security
- RFC 5905: Network Time Protocol Version 4
- IEEE 1588-2019: Precision Clock Synchronization Protocol
- RFC 8915: Network Time Security for NTP