Core Network Services and Protocols
Operate the services every network depends on: DHCP, DNS, NTP, HTTP/S, SMTP, SNMP, and remote access protocols.
- Certification
- CompTIA Network+
- Recommended study time
- 5h 35m
- Status
- Not started
Recommended study time
About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson21 min
About 2,729 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Explain the request flow and failure signs for DHCP, DNS, and NTP.
- Match common services to their ports and transport protocols.
- Choose secure alternatives to legacy plaintext protocols.
Start here
About 8 minutes of reading, in 10 short parts.
Networks run on a set of background services that most users never think about: DNS turning names into addresses, DHCP handing out addresses automatically, and protocols like HTTP, SMTP, and SSH carrying specific kinds of traffic. When one of these fails, the symptom is often confusing, because the network itself may be perfectly healthy while a single service is broken.
Where you meet it: A user reports 'the internet is down' but can actually reach IP addresses directly; the real fault is a DNS server that stopped responding, not the network connection itself.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
DNS is like a phone book: you know a person's name but the phone system needs their number, so DNS translates a name like a website into the address a computer actually needs. DHCP is like a hotel front desk automatically assigning a room number to every guest as they check in, so nobody has to be told their room number manually.
Beyond those two, dozens of other protocols each carry one specific kind of conversation: email uses one protocol to send and different ones to retrieve, web pages use one, remote administration uses another, and file transfer uses yet another. Each protocol has an agreed 'door number', called a port, so a server knows which service a given connection is asking for.
Key ideas
If you remember nothing else from this topic, remember these.
- DNS resolves human-readable names to IP addresses, and a failure here often looks identical to a total outage even though the network path itself is fine.
- DHCP automatically assigns IP addressing information to hosts through a four-step process commonly abbreviated DORA: Discover, Offer, Request, Acknowledge.
- Well-known ports identify which service a connection is intended for, and most troubleshooting of application connectivity comes down to confirming the correct port is open and listening.
- NTP keeps device clocks synchronized, and clock drift can silently break authentication protocols and certificate validation even though the network itself is healthy.
- Application layer protocols like HTTP, FTP, SMTP, and SNMP each have both an unencrypted legacy version and a secured, encrypted successor commonly used in production.
- Troubleshooting a service failure means confirming DNS resolves correctly, the correct port is reachable, and the service itself is actually running, in that order.
Resolving an intermittent email delivery failure
A worked example, step by step.
Users report that outgoing email to one specific partner company sometimes fails, while all other mail delivery works normally.
- 01Confirm DNS resolutionRun nslookup on the partner's mail domain and confirm an MX record is returned pointing to their mail server hostname.
- 02Check name-to-address resolutionResolve that mail server hostname to an IP address and note that it occasionally returns a different address, suggesting a round-robin DNS setup on the partner's side.
- 03Test the SMTP portRun telnet mailserver 25 against each returned address and find that one of the two IPs never accepts a connection.
- 04Isolate the patternCorrelate failed delivery timestamps with which of the two IPs was returned by DNS at that moment, confirming the fault matches the unreachable IP.
- 05Check for a firewall blockReview the outbound firewall log and find no matching deny entries, ruling out a local block.
- 06Escalate externallyContact the partner company and report that one of their two published mail server addresses does not accept SMTP connections on port 25.
- 07Apply a temporary mitigationConfigure the internal mail relay to prefer the known-working address while the partner investigates.
- 08Confirm resolutionAfter the partner fixes their failing server, retest delivery across several send attempts and confirm consistent success.
Outcome: The intermittent failure was traced to one of two load-balanced mail servers being down on the partner's end, found by testing DNS, port reachability, and correlating timing rather than assuming a local fault.
Common ports and network services
Worth keeping at hand while you work.
- DNS
- Port 53, resolves names to IP addresses
- DHCP
- Ports 67 (server) and 68 (client), assigns IP configuration automatically
- HTTP
- Port 80, unencrypted web traffic
- HTTPS
- Port 443, encrypted web traffic using TLS
- FTP
- Ports 20 (data) and 21 (control), unencrypted file transfer
- SFTP
- Port 22, file transfer secured over SSH
- SSH
- Port 22, encrypted remote administration
- Telnet
- Port 23, unencrypted remote administration, considered insecure
- SMTP
- Port 25, sends outgoing email between mail servers
- POP3
- Port 110, retrieves email and typically removes it from the server
- IMAP
- Port 143, retrieves email while keeping it synchronized on the server
- NTP
- Port 123, synchronizes device clocks
- SNMP
- Port 161, monitors and manages network devices
Common misunderstandings
What most beginners get wrong here.
DNS failures cause a connection refused error.
DNS failures typically cause a resolution error such as name not found, distinct from a connection refused error, which indicates the host was reached but the port rejected the connection.
DHCP only assigns an IP address.
DHCP typically also delivers the subnet mask, default gateway, DNS server addresses, and lease duration, not just the IP address itself.
SNMP and NTP are unimportant, purely background protocols.
SNMP failures blind monitoring systems to real outages, and NTP drift can break certificate validation and authentication tokens, both with serious operational impact.
FTP is a secure way to transfer files because it requires a login.
Standard FTP transmits credentials and data in plaintext; SFTP or FTPS should be used for secure transfer.
A working ping to a mail server means email will definitely be delivered.
Ping only confirms basic reachability at layer 3; the SMTP service on port 25 could still be down, misconfigured, or blocked.
Exam traps
How the question writers try to catch you out.
- Network+ expects memorization of well-known port numbers and will test both direction (name to port) and reverse (port to name) matching.
- Scenario questions often describe a DNS failure symptom, such as a website not found by name but reachable by IP, and expect DNS to be identified as the fault.
- DHCP questions frequently test knowledge of the DORA process order: Discover, Offer, Request, Acknowledge.
- Expect a distractor pairing SFTP with port 21 instead of its correct port 22, since it is easily confused with standard FTP.
- NTP-related exam scenarios describe authentication or certificate failures and expect clock synchronization to be considered as a root cause.
- Questions may ask which port to allow through a firewall for a described business need, requiring you to map the business requirement to the correct protocol and port.
Check yourself
Answer in your head first, then reveal. This is not scored.
What are the four steps of the DHCP process in order?
What port does HTTPS use, and what does it use for encryption?
Why might a website be unreachable by name but reachable by direct IP address?
What is the security difference between FTP and SFTP?
Why does clock drift matter on a network even if connectivity looks fine?
What port does SNMP use for network device monitoring?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
DHCP leases addressing through discover, offer, request, and acknowledge. DNS resolves names to records. NTP synchronises clocks, which authentication and logging depend on. Application services include HTTP/HTTPS (80/443), SMTP (25/587), IMAP (993), SSH (22), RDP (3389), and SNMP (161) for monitoring.
Why It Matters
Kerberos authentication fails when clocks drift. Certificate validation fails when time is wrong. Users cannot work without DHCP or DNS. These few services explain a large share of enterprise incidents.
How It Works
- DHCP clients broadcast, servers offer, clients request, and servers acknowledge with options such as gateway and DNS.
- DNS resolvers cache answers for their TTL, querying authoritative servers on miss.
- NTP clients discipline the local clock gradually toward the selected source.
Where You See It
- Every corporate LAN, guest Wi-Fi, data centre, and cloud VPC with managed DHCP and DNS.
Key Terms
- DHCP relay
- Forwards client broadcasts to a server on another subnet.
- Lease
- The time-bound assignment of an address to a client.
- Stratum
- An NTP source's distance from a reference clock.
- Well-known port
- Ports 0-1023 assigned to standard services.
- Reservation
- A DHCP mapping that always gives one device the same address.
Examples
- A DHCP relay is required when clients and the DHCP server are in different broadcast domains.
- Clock skew beyond five minutes typically breaks Kerberos authentication in Active Directory.
Common Problems
- Exhausted DHCP scope
- Rogue DHCP server
- Incorrect DNS server option
- Clock drift
- Blocked service port
How It Fails
- A rogue DHCP server hands out wrong gateways to a subset of users, producing intermittent outages.
- Clock drift breaks authentication and makes logs impossible to correlate.
- A missing DHCP relay leaves an entire new VLAN without addressing.
How to Troubleshoot
- Check what the client actually received, not what the server should have sent.
- Query DNS directly with a diagnostic tool rather than trusting the browser.
- Verify time source and offset before investigating authentication failures.
Practical Knowledge
- Reserve addresses for infrastructure and printers instead of using static entries outside the scope.
- Point domain members at internal DNS only, with forwarders configured on the servers.
Exam Coverage
- DHCP, DNS, and NTP operation
- Common ports and protocols
- Secure protocol selection
Interview Questions
- Why is time synchronisation a security requirement?
- How do you detect a rogue DHCP server?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Capture a DHCP exchange and identify all four messages.
- 02List the ports for every service your organisation exposes externally.