CompTIA A+ Core 1: Summarize Services Provided by Networked Hosts

What Is a Networked Host?

A host—what is it, really? Basically, it’s any device on a network that has an address and can send or receive data. Some hosts are clients (laptops, phones, the usual suspects), because they go asking for things; others are the behind-the-scenes workhorses—servers, printers, NAS boxes, routers—keeping the whole machine humming, or trying to. For the CompTIA A+ Core 1 (220-1101) objective, though, the scope is tighter. You mainly need to recognize networked hosts that provide services to clients, remember the common ports they use, and know the first troubleshooting step when things go sideways.

And the terms? Worth separating. A hostname is the friendly label—think portal.corp.example. An IP address is the numeric one the network actually uses. One host can wear several hats at once, by the way (more than one service on a single box is not unusual at all). I’ve seen a Windows server doing file sharing, printing, DNS, and authentication all at once—messy, yes, elegant, no, but common enough that you should expect it on the exam. Why should you care about that? Because one user complaint can drag multiple host roles into the same swamp.

In a client-server model, clients ask and servers provide; in a peer-to-peer model, devices share directly with one another. The client-server model is the business favorite because it scales better, centralizes security, simplifies backups, and, honestly, is a lot easier to live with once the user count starts climbing. The second? Fine for tiny setups. After that, it gets tangled quickly—security, troubleshooting, everything.

For A+, think recognition, not deep server administration. Know what service does what, the common port, the likely symptom, and—this part matters—the first thing to check.

How Clients Depend on Host Services

Most network tasks follow a chain. A very specific one. Break it anywhere, and the whole thing may fail:

1. Link connectivity: The device connects by Ethernet or Wi-Fi.
2. IP configuration: The client gets addressing from DHCP, static configuration, or in IPv6 environments, possibly SLAAC and/or DHCPv6.
3. Gateway reachability: The client needs a valid default gateway for off-subnet traffic.
4. Name resolution: DNS resolves names to IP addresses.
5. Authentication: The user or device may need to authenticate to a domain, cloud identity provider, or application.
6. Service access: The client reaches a file share, printer, web app, email system, or another resource.

And here’s the catch—failures love disguises. “The internet is broken” might really be DHCP, DNS, proxy settings, authentication, or just some service sulking in the corner. So what’s the smart move? Figure out which dependency failed.

Take a shared network path, for example. Opening it may require working Wi-Fi, a valid IP address, DNS, Active Directory reachability, Kerberos time sync, SMB access, and correct permissions. If any one of those slips, what does the user see? Just: “I can’t open the drive.”

DHCP Servers

DHCP automatically assigns IPv4 settings—IP address, subnet mask, default gateway, DNS server addresses. Without DHCP or valid static configuration, a device may simply lack the information it needs to communicate beyond the local segment.

It uses UDP 67/68. The server listens on port 67, and the client sends from port 68. The lease process is DORA: Discover, Offer, Request, Acknowledge. No permanent ownership here—clients lease addresses for a period, then renew them.

Important A+ details:

• Scope: the pool of addresses the server can hand out.
• Exclusions: addresses the server will not assign.
• Reservations: a specific device always gets the same address, usually based on MAC address.
• Scope exhaustion: the pool runs out of available addresses.

Because DHCP requests are broadcasts, they usually stay inside one broadcast domain. If the DHCP server lives on another subnet or VLAN, the network typically needs a DHCP relay or IP helper—otherwise, well, the request just sits there shouting into the void.

And if DHCP fails on Windows? The client may assign itself an APIPA address in the 169.254.0.1-169.254.255.254 range, often written as 169.254.x.x. That is link-local, not routed, so it usually does not provide internet access or access beyond the local link. A placeholder, basically. Not a real lease.

First checks: ipconfig /all, then ipconfig /release and ipconfig /renew. Also check link status, the SSID or VLAN, the default gateway, and whether other devices can get a lease. Simple. But not always easy.

DNS Servers

DNS translates names into IP addresses; it can also do reverse lookups from IP to name. It commonly uses UDP 53 for queries and TCP 53 for zone transfers and some larger responses.

Common record types to recognize:

• A: hostname to IPv4 address
• AAAA: hostname to IPv6 address
• CNAME: alias to another name
• MX: mail exchanger for email delivery
• PTR: reverse lookup

Clients lean on DNS constantly—web browsing, email, file shares by name, domain logon, all of it. In Active Directory environments, it becomes even more critical. Many “authentication” problems? They’re really DNS problems.

There’s caching too. Great for speed, until it isn’t... because stale entries can cause bizarre behavior. On Windows, flush the cache with ipconfig /flushdns.

Common symptom: you can reach an IP address but not the hostname. Use nslookup to test name resolution and confirm the client is using the correct DNS server. And remember—internal and external DNS may answer differently for the same service name in some environments.

File Servers and NAS

Modern Windows file sharing primarily uses SMB over TCP 445. You may still hear CIFS, but that’s older terminology tied to legacy SMB dialects. For current A+ study, think SMB.

Users reach file shares through a UNC path or a mapped drive like H:. If the mapping fails, test the direct network path first—don’t jump straight to “the server is dead.”

Permissions matter. In Windows environments, access can depend on both share permissions and NTFS permissions. Often the most restrictive effective permission wins (annoying? absolutely), which is why one user sees Access denied while another opens the same folder with no trouble.

A NAS appliance also provides file-level network storage, usually over SMB and sometimes NFS. A SAN is different: block storage to servers rather than file shares directly to end users. For A+, just remember NAS = shared file storage over the network.

First checks: verify the path, test connectivity, confirm name resolution, try net use, and determine whether the issue affects one user or everyone.

Print Servers and Network Printing

Printing questions are often really questions about where the job is getting stuck. The client? The print server? The printer itself? One of those, usually.

Common printing methods and ports:

• TCP 9100: raw printing / JetDirect / AppSocket
• TCP 631: IPP (Internet Printing Protocol)
• TCP 515: LPD/LPR
• SMB shared printers: common in Windows server-managed environments

A printer can be:

• Local: directly attached to one PC
• Direct-IP: the client prints straight to the printer’s network address
• Shared through a print server: the server manages the queue and often the drivers

The print spooler handles queued jobs. One bad document can jam the queue—and then everyone looks broken even though the hardware is fine.

First checks: one user or all users? Then the queue, then whether the printer shows online, then basic IP connectivity, then the driver—wrong or out of date? If needed, restart the spooler and clear stuck jobs.

Typical Windows spooler recovery: stop the Print Spooler service, clear pending jobs, then start the service again.

Mail Servers

Email uses different protocols for sending and receiving. Strange, but useful to keep separate.

Sending:
• SMTP 25: typically server-to-server relay
• SMTP submission 587: standard client submission, usually with STARTTLS
• 465: commonly used in some environments for implicit TLS submission

Receiving:
• POP3 110 / 995 secure
• IMAP 143 / 993 secure

For A+, the core idea is simple: SMTP sends; POP3/IMAP receive. POP3 is more download-oriented, while IMAP keeps mail synchronized across devices.

Mail flow also leans on DNS, especially MX records for delivery between mail systems. So yes—a mail issue can be a DNS issue in disguise.

In modern environments, users may be on Microsoft 365 or Google Workspace, and the client may rely on autodiscover or modern authentication instead of manual server settings. Still, the troubleshooting logic stays the same: check internet access, account sign-in, MFA prompts, server settings if exposed, and whether the issue is local or service-wide.

Common symptom: can receive but not send. That usually points to SMTP submission settings, authentication, or TLS requirements.

Web Servers

Web servers deliver websites and web applications over HTTP 80 and HTTPS 443. HTTPS uses TLS to provide confidentiality, integrity, and server identity validation through certificates.

When troubleshooting web access, separate the layers—because they do not fail in the same way:

• DNS problem: name does not resolve correctly
• Connectivity problem: server cannot be reached
• Proxy problem: browsing path is blocked or misconfigured
• TLS/certificate problem: expired certificate, name mismatch, untrusted issuer, or wrong device time
• Application problem: the site loads but the app itself fails

Certificate warnings do not automatically mean the site is down. Often—maybe half the time, sometimes more—it’s just the browser saying, “Yes, I reached the server, but this certificate looks off.” Causes? Wrong URL, expired certificate, mismatched hostname, broken trust chain, incorrect system date/time.

Authentication and Directory Servers

Directory services centralize identities, groups, and access control. In Microsoft environments, that usually means Active Directory and one or more domain controllers.

Important distinction: LDAP and LDAPS are directory access protocols, commonly 389 and 636. In Active Directory, however, Kerberos on TCP/UDP 88 is the primary authentication protocol for domain logon. So no, LDAP is not the same thing as Kerberos.

AD access commonly depends on several services working together: DNS, Kerberos, LDAP, SMB, and other supporting services. Which is why a DNS misconfiguration can break logon, mapped drives, printers, and internal apps all at once.

Time matters too. Kerberos is sensitive to clock skew, so NTP on UDP 123 supports healthy authentication. If the system time is far off, domain authentication can fail even when the password is correct.

Common symptoms: account lockout, disabled account, expired password, device not joined to the domain, cached local sign-in works but domain resources fail, or Group Policy does not apply as expected.

Proxy Servers

A forward proxy sits between clients and outside resources, often for filtering, logging, caching, or policy enforcement. A reverse proxy sits in front of servers and represents them to clients. For A+, the client-side troubleshooting focus is usually the forward proxy.

Proxy settings may be configured manually, by policy, with a PAC file, or through WPAD. Bad proxy configuration can break web access even when IP connectivity and DNS are perfect. That’s the annoying part.

Classic symptom: the laptop works at home but not at work, or the opposite. Often that points to stale proxy settings rather than a total internet outage.

Logging and Monitoring Hosts

Logging and monitoring systems help IT catch problems before users complain. Common examples:

• Syslog: centralized log collection, commonly UDP 514; secure syslog commonly uses TCP 6514
• SNMP: device monitoring; UDP 161 for polling/queries and UDP 162 for traps/informs

Polling means the monitoring system asks devices for status. Traps are notifications devices send when something happens. Also know that SNMPv3 adds security features older SNMPv1/v2c do not have.

These hosts may not be visible to end users, but they matter because they help administrators spot outages, high CPU, low disk space, printer failures, and network problems quickly.

IPv6 Host Services Basics

A+ can include basic IPv6 awareness. IPv6 clients may use SLAAC, DHCPv6, or both. IPv6 also uses link-local addresses automatically. DNS may return AAAA records for IPv6 destinations. The exam point is the same as always: clients still need addressing, name resolution, and service reachability, even when the network is using IPv6 instead of IPv4.

Common Ports by Function

Name and addressing: DNS 53, DHCP 67/68, NTP 123
Web: HTTP 80, HTTPS 443
Mail: SMTP 25, submission 587, implicit TLS 465, POP3 110/995, IMAP 143/993
File and print: SMB 445, LPD 515, IPP 631, JetDirect 9100
Directory and auth: LDAP 389, LDAPS 636, Kerberos 88
Remote admin: SSH 22, RDP 3389
Monitoring: SNMP 161/162, Syslog 514

Two accuracy notes: FTP uses TCP 21 for control and traditionally TCP 20 for active-mode data, but passive mode uses negotiated high ports. Also, ping uses ICMP, not a TCP or UDP port.

Troubleshooting by Symptom

169.254.x.x address: likely DHCP failure. Check ipconfig /all, renew the lease, verify DHCP reachability, and compare with a working device.

Can ping IP but not name: likely DNS. Use nslookup, verify DNS server settings, and try ipconfig /flushdns.

Can log in locally but not access shares: likely authentication, DNS, SMB, or permissions. Check account status, domain connectivity, time sync, and the direct network path.

Shared printer fails for everyone: likely print queue, spooler, print server, or printer connectivity. Check whether jobs are stuck and whether the printer is online.

Can receive but not send email: likely SMTP submission settings, authentication, or TLS mismatch.

One website fails with a certificate warning: likely TLS/certificate issue after basic DNS/connectivity. Check the address being used, time, expiration, and hostname match.

Browsing fails only on the corporate network: likely proxy or filtering policy.

Useful Windows commands for this topic:

• ipconfig /all — view IP settings
• ipconfig /release and /renew — refresh DHCP lease
• ipconfig /flushdns — clear DNS cache
• ping — basic reachability test
• nslookup — DNS test
• tracert — Windows path test; traceroute is the Unix-like equivalent
• net use — view or reconnect mapped drives
• w32tm /query /status — check Windows time status when Kerberos/time skew is suspected

Security and Modern Best Practices

Prefer secure protocols when possible: HTTPS over HTTP, IMAPS/POP3S or TLS-enabled mail over plaintext retrieval, LDAPS or LDAP with StartTLS over plaintext LDAP, and secure file transfer methods over legacy FTP. Also remember that SMBv1 is deprecated and insecure. Least privilege still matters—users should have only the access they need, especially on file shares and printers.

Cloud vs On-Premises Troubleshooting

The hosting location changes, but the client-side checks do not. Whether the service is on-premises or SaaS, start with local connectivity, DNS, browser or client settings, authentication, and whether the problem is local or affecting multiple users. If Microsoft 365 email fails, for example, you’d still check internet access, account sign-in, and local client behavior before escalating to a tenant administrator or checking provider service status through the appropriate administrative tools.

Exam Traps and Final Review

Watch for the common traps—easy to mix up if you’re moving too fast:

• DNS is not DHCP. DHCP gives IP settings; DNS resolves names.
• LDAP is not Kerberos. LDAP is directory access; Kerberos is primary AD authentication.
• Certificate warning does not automatically mean the server is down.
• APIPA means no IPv4 lease, not necessarily total hardware failure.
• A file share problem may be permissions, authentication, DNS, or server reachability.

Final cram checklist: know the service role, the common port, one typical symptom, and the first troubleshooting step. If you can map user complaints to DHCP, DNS, SMB, print services, mail, web, authentication, proxy, or monitoring, then you’re studying this objective the right way... and yes, that’s the goal.