I1.4 DNS, DHCP, and Common Network Services
Analyze fictional name resolution, address assignment, time synchronization, directory, trust, and monitoring evidence as connected network-service dependencies.
Lesson Progress
DNS, DHCP, and Common Network Services
High School Intermediate • I1: Networking for Defenders • Lesson 4 of 8
Readiness Check
Before You Start
0/4 ready
Professional Hook
A Website Failure May Begin With Name Resolution, Address Assignment, Time, Identity, or Another Dependency
A browser error may look like an application problem even when the device received the wrong gateway, the DNS record still points to an old service, the system clock is far out of sync, or the directory account was moved into the wrong group. Intermediate defenders map these dependencies and compare evidence across services.
Weak response
“The page failed, so DNS must be broken.”
Strong response
“Identify the dependency, compare client and service records, align timestamps, check approved design, and isolate the lowest supported failure.”
Objective 1
Explain the defensive roles of DNS, DHCP, NTP, directory, and other common network services.
Objective 2
Correlate fictional DNS queries, DHCP leases, device identities, timestamps, and service records.
Objective 3
Identify signs of misconfiguration, stale records, wrong scopes, failed resolution, and service dependency problems.
Objective 4
Distinguish what each service record confirms from what still requires supporting evidence.
Objective 5
Recommend safe, authorized, and reversible next actions for common network-service issues.
Why This Matters
Core Services Quietly Support Nearly Every Networked Workflow
DNS helps systems find services. DHCP helps devices receive usable network settings. NTP keeps evidence aligned. Directory services connect identities and roles. Certificate and monitoring services support trust and visibility. When one dependency is wrong, many applications can fail at the same time.
Network Service Guide
Common Services Create Dependencies and Evidence
Service
DNS
Main role
Translates approved names into address information and supports service discovery.
Useful evidence
Queries, responses, record type, resolver, returned value, TTL, response code, and time.
Defender questions
Which resolver answered? Was the name expected? Did the answer change? Did a later connection occur?
Service
DHCP
Main role
Automatically provides approved address, prefix, gateway, DNS, and lease information.
Useful evidence
Device identifier, offered address, scope, lease start, lease end, gateway, DNS options, and VLAN context.
Defender questions
Did the correct scope answer? Does the lease match the device, subnet, VLAN, gateway, and design?
Service
NTP
Main role
Helps systems maintain consistent time for logs, alerts, authentication, and investigations.
Useful evidence
Configured time source, sync state, offset, last successful update, and local time.
Defender questions
Are clocks aligned? Could time drift explain misleading event order or failed authentication?
Service
Directory
Main role
Stores approved identity, group, device, and access context for organizational systems.
Useful evidence
Account status, group membership, device record, role, authentication result, and change history.
Defender questions
Is the identity active? Does the group match the device and requested service? Was a recent change approved?
Service
Certificate or trust service
Main role
Supports certificate validation, trust chains, and secure service identity concepts.
Useful evidence
Certificate subject, issuer, validity period, chain status, and revocation-check result.
Defender questions
Is the certificate expected, current, and associated with the correct service name?
Service
Monitoring and logging
Main role
Collects health, event, performance, and security records from approved sources.
Useful evidence
Source status, collection time, missing records, event volume, health checks, and alerts.
Defender questions
Is the source reporting? Are timestamps aligned? Is an absence of evidence caused by collection failure?
Core Concept
A Service Record Is a Time-Bounded Observation, Not Permanent Truth
DNS answers may be cached, DHCP leases expire, directory membership changes, certificates reach expiration, and clocks drift. Defenders must compare record values, timestamps, TTLs, lease windows, synchronization state, approved changes, and current ownership.
Key Vocabulary
Intermediate DNS, DHCP, and Service Terms
DNS resolver
A service that answers or forwards name-resolution requests for clients.
DNS record
A stored entry that connects a name with information such as an address, alias, or mail service.
A record
A DNS record that maps a name to an IPv4 address.
AAAA record
A DNS record that maps a name to an IPv6 address.
CNAME record
A DNS record that points one name to another canonical name.
TTL
Time to live: the length of time a DNS answer may remain cached before being refreshed.
DHCP scope
A configured range of addresses and options available for automatic assignment.
DHCP lease
A time-limited assignment connecting a device or interface with an address and network options.
Reservation
A DHCP rule that consistently offers a selected address to a specific approved device identifier.
NTP
Network Time Protocol concepts used to keep system clocks aligned for reliable logs and correlation.
Directory service
A service that stores and organizes identities, groups, systems, and access-related information.
Dependency
A service, system, or configuration that another service needs in order to work correctly.
DNS Outcomes
Read the Response Without Overclaiming
Successful answer
The resolver returned a record for the requested name.
NXDOMAIN
The resolver reports that the requested name does not exist in the queried DNS context.
Timeout
The client did not receive a response within the expected window.
Unexpected answer
The returned address or alias differs from the approved record or baseline.
ServFail
The resolver could not complete the request successfully.
DHCP Outcomes
Compare Assignment Evidence With Approved Design
Expected lease
Approved device receives an address, gateway, DNS server, and lease duration from the correct scope.
Wrong scope
A device receives an address or gateway belonging to a different subnet or zone.
No lease
The device uses a link-local address or lacks expected gateway and DNS options.
Duplicate or conflicting assignment
Two systems appear connected to the same address or records disagree during the same time window.
Stale reservation
A reserved address points to a retired or replaced device identifier.
Evidence Analysis
What Common Service Records Can and Cannot Prove
Evidence source
DNS query log
Can support
Requested name, resolver, record type, answer, response code, TTL, and timestamp.
Limitation
Does not prove that a later connection or application action occurred.
Evidence source
DHCP lease log
Can support
Device identifier, assigned address, scope, gateway, DNS option, and lease window.
Limitation
Does not prove the identity of every user or the purpose of all later traffic.
Evidence source
Endpoint configuration
Can support
The address, prefix, gateway, DNS servers, search suffix, and interface currently shown on a device.
Limitation
May reflect stale local state unless compared with server-side records and timestamps.
Evidence source
Directory record
Can support
Approved account, device, group, role, or ownership context.
Limitation
Does not prove that technical configuration or current activity matches the record.
Evidence source
NTP status
Can support
Whether the system clock is synchronized and the size of any offset.
Limitation
Does not explain the entire incident, but poor time alignment can distort correlation.
Evidence source
Change ticket
Can support
Approved reason, timing, owner, affected records, test plan, and rollback plan.
Limitation
Does not prove the change was implemented exactly as documented.
Defensive Workflow
Review a Network-Service Problem in Six Steps
Identify the dependency
Determine which service the application or device needs: name resolution, address assignment, time, identity, trust, or logging.
Collect both client and server evidence
Compare the device view with the DNS, DHCP, directory, NTP, or monitoring service records.
Align timestamps
Confirm time zones, clock synchronization, lease windows, cache windows, and change timing.
Check design and ownership
Compare records with approved scopes, names, zones, owners, roles, and service dependencies.
Separate cause from symptom
A failed website may begin with DNS, DHCP, time, identity, routing, or application evidence.
Recommend a controlled correction
Use authorization, documentation, testing, rollback, validation, and monitoring.
Fake Dashboard
Fake Network Services Health Dashboard
Training dashboard for the fictional Ridgeway Learning Network. It compares DNS, DHCP, NTP, directory, and monitoring health.
DNS health
Warning
One approved application name still returns the retired documentation address after migration.
DHCP health
Healthy
Managed devices are receiving the expected subnet, gateway, and resolver options.
Time alignment
Degraded
One application server is seven minutes behind the approved time source.
Fake SOC Alert
Old DNS Record and Time Drift Affect an Approved Application
Source: Fake Network Services Monitor • Time: 02:18 PM
Fake Log Panel
Fake Common-Service Evidence Timeline
13:40:00 CHANGE migration='student-portal-v2' approved='true' status='complete' 13:42:10 DNS query='portal.ridgeway-training.test' answer='192.0.2.40' ttl='3600' 13:42:14 APP_V1 address='192.0.2.40' status='retired' response='maintenance' 13:43:02 APP_V2 address='198.51.100.24' status='healthy' 13:45:30 NTP host='app-v2' offset='-00:07:03' sync='degraded' 13:47:12 AUTH host='app-v2' result='success' event_time='13:40:09' 13:50:41 DNS_DESIGN alias='portal.ridgeway-training.test' expected='app-v2.ridgeway-training.test' 14:18:04 CORRELATION findings='stale_dns_alias,time_drift' confidence='high'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Service Explanation Is Best Supported?
What is the strongest conclusion and next action?
Common Mistakes
Mistakes That Weaken Common-Service Analysis
Safe Practice Lab
Build a Fictional Network-Service Dependency Map
Fictional Environment
Meadowbrook Digital Learning Platform
The fictional platform depends on DNS, DHCP, NTP, directory authentication, certificates, and centralized monitoring. Students receive client settings, service logs, health records, design documents, and approved change tickets.
Required Analysis
- Draw the dependency path from device startup to application login.
- Label the evidence produced by each service.
- Compare client-side and server-side records.
- Align TTL, lease, time-sync, authentication, and change windows.
- Identify one stale record, one wrong scope, and one timing problem.
- State what is confirmed, likely, uncertain, and still missing.
- Write an authorized correction, validation, and rollback plan.
Scenario Decision Lab
A Device Has the Correct Address but the Wrong DNS Resolver
A fictional managed device receives the expected address, prefix, and gateway but uses a retired DNS resolver. Other devices on the same subnet use the approved resolver and can reach the learning portal.
Scenario Decision Lab
Events Appear Out of Order Across Two Systems
A fictional endpoint reports a login at 09:10, while the application server records the same login at 09:03. NTP status shows the application server is seven minutes behind.
Defender Habits
DNS, DHCP, and Common Services Review Checklist
Check Your Understanding
I1.4 Mini Quiz: DNS, DHCP, and Common Network Services
Choose your answers first. Explanations appear only after submission.
1. What does a successful DNS response prove?
2. What does a DHCP lease commonly contain?
3. Why is NTP important to defenders?
4. What may an NXDOMAIN result indicate?
5. Which evidence best connects an address to a device during a specific time window?
6. What is the strongest response to a stale DNS record after an approved migration?
7. Why should client and server evidence both be reviewed?
Portfolio Prompt
Portfolio Prompt
Create a fictional Network-Service Dependency and Evidence Map for a small learning organization. Show device startup, DHCP, DNS, NTP, directory authentication, certificate validation, application access, and monitoring. For each service, include its owner, purpose, inputs, outputs, evidence, failure symptoms, evidence limits, and validation method. Add one fictional stale DNS record, one wrong DHCP option, and one time-drift issue.
Key Takeaways
What You Should Remember
Navigation