Every functional network depends on a small set of foundational services that operate silently behind the scenes. When you type a website address into a browser, a chain of automated systems translates that name to a numeric address, assigns your device a valid network configuration, routes your packets through the correct network segment, and — when needed — encrypts your traffic across an untrusted link. These services are DNS, DHCP, VLANs, and VPNs.
For the A+ technician, these concepts appear constantly in the field. A device that "can't connect to the internet" is almost always a DNS, DHCP, or default gateway problem. A user who needs to access corporate resources from home requires a VPN. Segmenting a company's employee traffic from guest Wi-Fi requires VLANs. Understanding how each service works — not just what acronym it stands for — is the difference between guessing and diagnosing.
Core Concept
The four technologies in this objective work as a layered system: DHCP automatically assigns IP addresses, subnet masks, default gateways, and DNS server addresses to devices when they join the network. DNS translates human-readable hostnames into IP addresses so devices can actually reach each other. VLANs logically segment a single physical network into isolated broadcast domains. VPNs create encrypted tunnels across untrusted networks so remote devices can participate in a private network securely.
The Domain Name System (DNS) is the internet's distributed phonebook. Every device on a network is identified by a numeric IP address — but humans cannot reasonably memorize millions of IP addresses. DNS solves this by maintaining a globally distributed, hierarchical database that maps human-readable hostnames (like www.example.com) to their corresponding IP addresses.
DNS is a critical dependency for nearly all network activity. When DNS fails, users perceive it as "the internet is down" — even though the underlying network connectivity is intact. Diagnosing DNS failures (using tools like nslookup and ping) is a fundamental A+ skill. A device that can ping 8.8.8.8 but cannot reach www.google.com has a DNS problem, not a connectivity problem.
ipconfig /displaydns on Windows) for a recently resolved record. If a valid cached record exists, it is returned immediately — no network query needed..com TLD server for example.com)..com, .org, .net, etc.) knows which authoritative name server is responsible for the specific domain (example.com) and directs the resolver there.www.example.com to 93.184.216.34).A DNS zone is composed of individual resource records (RRs). Each record type stores a different kind of information about a domain. The A+ exam requires familiarity with the five most common record types: A, AAAA, CNAME, MX, and TXT.
The A record (Address record) is the most fundamental DNS record type. It maps a hostname to a 32-bit IPv4 address. When your browser resolves www.google.com, it is ultimately retrieving an A record that contains a numeric IPv4 address like 142.250.80.36.
hostname → IPv4 address (e.g., 93.184.216.34). A single hostname can have multiple A records (for load balancing — clients cycle through them), and a single IP can be pointed to by multiple A records (multiple domains hosted on one server).
The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. It maps a hostname to a 128-bit IPv6 address. The name "AAAA" reflects that an IPv6 address is four times the size of an IPv4 address (128 bits vs. 32 bits).
Modern dual-stack networks publish both A and AAAA records for the same hostname. When a client that supports IPv6 queries DNS, it typically requests both record types simultaneously. If an AAAA record is available, the operating system will prefer the IPv6 address for the connection (per RFC 6724 address selection rules). If AAAA is unavailable, it falls back to the A record and uses IPv4.
A vs. AAAA — The Key Difference
A record → 32-bit IPv4 address (e.g., 192.168.1.1). AAAA record → 128-bit IPv6 address (e.g., 2001:db8::1). Both serve the same purpose — hostname-to-IP mapping — but for different protocol versions. On the A+ exam, if a question involves IPv6 name resolution, the answer involves AAAA records.
A CNAME record (Canonical Name record) creates an alias — it maps one hostname to another hostname rather than directly to an IP address. The alias is resolved by following the chain: the CNAME points to the canonical name, which is then resolved to an IP via its own A or AAAA record.
Example: A company hosts its online store on Shopify's platform. Shopify assigns them a canonical address of storefront-12345.myshopify.com. The company creates a CNAME record mapping shop.example.com → storefront-12345.myshopify.com. Customers can visit shop.example.com and DNS transparently resolves it through Shopify's infrastructure without the company managing Shopify's IP addresses directly.
CNAME Restrictions
A CNAME cannot exist for the zone apex (the root domain itself, e.g., example.com with no subdomain). A CNAME at the apex would conflict with required SOA and NS records. A CNAME also cannot point to an MX or NS record — only to another hostname. Using a CNAME where an A record is required is a common configuration error that causes complete name resolution failure for the aliased resource.
The MX record (Mail Exchanger record) specifies which mail server(s) are responsible for accepting inbound email for a domain. When someone sends email to user@example.com, the sending mail server queries DNS for the MX records of example.com to determine where to deliver the message.
MX records include a priority value (a lower number = higher priority). If a domain has multiple MX records, sending servers try the highest-priority (lowest-numbered) server first, falling back to lower-priority servers if the primary is unavailable. This provides built-in mail delivery redundancy.
The TXT record stores arbitrary human-readable or machine-readable text data associated with a domain. Originally intended for annotations, TXT records have become the de facto standard for domain verification and email authentication because they are easy to create and are globally queryable by any mail server or service.
Common uses of TXT records include domain ownership verification (proving to Google or Microsoft that you control a domain), email authentication policies (SPF, DKIM, DMARC — covered in the next subsection), and service configuration metadata.
Email was designed in the 1970s with no sender authentication whatsoever. Anyone can configure a mail server to send email claiming to be from @anybank.com or @yourcompany.com — a practice called email spoofing that enables phishing, business email compromise, and spam campaigns. Three complementary DNS-based standards were developed to address this: SPF, DKIM, and DMARC. Together, they form the modern email authentication framework used by virtually every major organization.
The Problem These Standards Solve
The SMTP protocol that delivers email has no built-in mechanism to verify that a sender is who they claim to be. A spoofed email claiming to be from ceo@company.com is indistinguishable at the protocol level from a legitimate email sent by the actual CEO — unless the receiving server checks SPF, DKIM, and DMARC records in DNS. These three standards allow receiving mail servers to cryptographically verify sender authenticity and take policy-defined action on failures.
SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email on behalf of a domain. When a receiving mail server gets a message claiming to be from user@example.com, it queries DNS for the SPF record of example.com and checks whether the sending server's IP address is on the authorized list.
ip4:203.0.113.10 authorizes a single IP; ip4:203.0.113.0/24 authorizes a /24 subnet.
include:_spf.google.com imports Google's full list of authorized sending IPs for Google Workspace.
~all (soft fail) marks unauthorized senders as suspicious but doesn't reject. ?all (neutral) takes no action.
MAIL FROM: address used during SMTP), not the From: header that users see in their email client. Sophisticated phishing attacks can pass SPF while still displaying a spoofed From address. This is why DKIM and DMARC are needed in addition to SPF.
DKIM (DomainKeys Identified Mail) uses public-key cryptography to digitally sign outgoing emails. The sending mail server adds a DKIM-Signature header to each outgoing message, containing a cryptographic signature of selected message headers and the message body. The corresponding public key is published in a DNS TXT record. Receiving servers retrieve the public key and use it to verify that the signature is valid — proving the message was sent by a server holding the private key and that the signed portions have not been modified in transit.
How DKIM Signing Works
Sending side: The outgoing mail server uses its private key to generate a cryptographic hash of selected message headers (From, Subject, Date) and body content. This hash is encoded and attached to the message as the DKIM-Signature header. Receiving side: The receiving server reads the DKIM-Signature header, fetches the domain's public key from DNS, and attempts to verify the signature. If the signature verifies successfully, the message is authentic and unmodified. If verification fails, the message may have been tampered with or was not sent by an authorized server.
s=mail) and in the DNS record name (mail._domainkey.example.com).
From: address if the attacker controls a domain that has valid DKIM configured. DMARC ties DKIM and SPF together and adds the policy enforcement layer.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that ties SPF and DKIM together. A DMARC TXT record published by a domain tells receiving mail servers two things: (1) how to handle messages that fail SPF and/or DKIM alignment, and (2) where to send reports about authentication results. DMARC closes the gap that SPF and DKIM leave individually — it enforces that the visible From: address is aligned with an authenticated domain.
MAIL FROM or DKIM signature aligns (matches) with the From: header domain that users see. This is the key feature that prevents sophisticated spoofing — even an attacker with a valid SPF record for a different domain cannot pass DMARC alignment for example.com.
p=reject.
Exam Focus — SPF, DKIM, DMARC
SPF = TXT record listing authorized sending IPs; validated against the SMTP envelope sender. DKIM = cryptographic signature on outgoing email; public key published as TXT record; survives forwarding. DMARC = policy TXT record at _dmarc.domain; ties SPF and DKIM together; defines what to do with failures (none / quarantine / reject); sends aggregate reports. All three are DNS TXT records. DMARC is the "enforcement" layer — SPF and DKIM are the mechanisms it evaluates.
| Standard | DNS Record | What It Checks | What It Proves | Limitation |
|---|---|---|---|---|
| SPF | TXT at domain root | Sending server IP vs. authorized list | Mail came from an authorized server | Breaks on forwarding; only checks envelope, not From: header |
| DKIM | TXT at selector._domainkey.domain | Cryptographic signature in email header | Message was signed by a key holder and wasn't modified | No policy enforcement; doesn't reject failures on its own |
| DMARC | TXT at _dmarc.domain | SPF + DKIM alignment with From: header | Policy-enforced alignment; reports unauthorized senders | Requires SPF and DKIM to be correctly configured first |
The Dynamic Host Configuration Protocol (DHCP) automates network configuration for client devices. Without DHCP, every device joining a network would require manual configuration of its IP address, subnet mask, default gateway, and DNS server addresses. DHCP eliminates this administrative burden by automatically assigning these parameters to devices when they connect — a process that takes milliseconds and requires no user interaction.
DHCP operates on a client-server model. A DHCP server maintains a pool of available IP addresses and configuration parameters. A DHCP client (any device that needs an IP address) broadcasts a request when it connects to the network. The server selects an available address, assigns it to the client for a defined period (called a lease), and delivers it along with all other network parameters.
DHCP address assignment follows a four-step handshake known by the acronym DORA: Discover, Offer, Request, Acknowledge. This process completes automatically in milliseconds each time a DHCP client connects to a network.
Why the Discover is a Broadcast
When a client first connects, it has no IP address — therefore it cannot address a unicast packet to a specific server. DHCP Discover messages are sent from source 0.0.0.0 to destination 255.255.255.255 (limited broadcast). All devices on the local network segment receive the broadcast. Only DHCP servers respond with Offers. If the DHCP server is on a different subnet, a DHCP relay agent (often configured on the router) forwards the broadcast as a unicast to the remote server.
A DHCP lease is the period of time for which a client is authorized to use an assigned IP address. The DHCP server sets the lease duration; typical values range from 1 hour (for high-turnover environments like hotel Wi-Fi) to 8 days (for stable corporate networks).
169.254.0.0/16. An APIPA address means DHCP has failed — the device can communicate only with other APIPA-addressed devices on the same segment, not with the internet or other network resources. APIPA addresses are the primary symptom of DHCP failure to recognize on the A+ exam.
/release followed by /renew forces a full DORA cycle and is the standard first step for DHCP troubleshooting.
A DHCP scope is the full range of IP addresses that a DHCP server is configured to assign for a given subnet. The scope defines the boundaries of address assignment — the server will only issue addresses within the scope to clients.
192.168.10.1 – 192.168.10.254 — the full subnet range eligible for DHCP assignment (excluding network address .0 and broadcast .255)
255.255.255.0 — defines the network boundary for all assigned addresses; delivered to every client with its lease
192.168.10.1 — the router interface address delivered to clients; required for internet and inter-subnet routing
8.8.8.8, 8.8.4.4 — DNS resolver addresses delivered to clients; can be corporate DNS servers or public resolvers
A DHCP exclusion is a specific address or range of addresses within the scope that the DHCP server will never assign dynamically. Exclusions are used to protect static IP addresses that have been manually configured on devices within the same subnet range — preventing the DHCP server from accidentally assigning those addresses to a different device and causing an IP address conflict.
Common devices requiring static IPs (and therefore DHCP exclusions) include routers, switches, servers, printers, access points, and network-attached storage devices. Best practice is to either use exclusions at the bottom of the scope range for static devices or to place all static devices in an entirely separate range outside the DHCP scope.
IP Address Conflict — What Happens
An IP address conflict occurs when two devices on the same network have the same IP address. Both devices will experience intermittent connectivity failures — whichever device's ARP reply arrives second is rejected. Windows detects conflicts and disables the NIC with an error. This is the consequence of not using exclusions for statically-configured devices. Always exclude all static IP addresses from DHCP scopes.
A DHCP reservation is a permanent lease assignment that always gives the same IP address to a specific device, identified by its MAC address. The DHCP server sees the device's MAC address in its DHCP Discover, matches it to a reservation record, and always offers that device the reserved IP address.
Reservations are the best of both worlds: the device's IP address is stable and predictable (like a static IP), but the address is still managed and distributed by DHCP (no manual interface configuration on the device). This makes reservations ideal for printers, servers, network cameras, and other devices that need a consistent IP but benefit from centralized DHCP management.
Exam Focus — DHCP
DORA = Discover, Offer, Request, Acknowledge — memorize this sequence. APIPA (169.254.x.x) = DHCP failure symptom. Scope = the full IP range a server manages. Exclusion = address(es) within the scope that will never be dynamically assigned (for static devices). Reservation = always assigns the same IP to a specific MAC address. ipconfig /release + ipconfig /renew = DHCP troubleshooting commands. A question about a device always needing the same IP → reservation, not static (on the A+ exam, reservation is the preferred enterprise answer).
| DHCP Concept | Definition | Exam Tip |
|---|---|---|
| Scope | Pool of addresses DHCP server manages and assigns for a subnet | A scope must exist before DHCP can assign any addresses on that subnet |
| Exclusion | Address range inside the scope the server will never assign dynamically | Use for devices with manually-configured static IPs within the scope range |
| Reservation | Always assigns a specific IP to a device identified by MAC address | Device still uses "DHCP" mode; IP is consistent without static config on device |
| Lease | Duration an assigned IP is valid; renewed at 50% and 87.5% elapsed time | Expired lease = no IP; APIPA appears when DHCP is unreachable |
| APIPA | 169.254.0.0/16 self-assigned address when DHCP fails | 169.254.x.x address on a device = DHCP server not found/not responding |
A VLAN (Virtual Local Area Network) is a logical network segmentation technique that divides a single physical network infrastructure into multiple isolated virtual networks. Devices on different VLANs cannot communicate with each other at Layer 2 — they behave as though they are on entirely separate physical networks, even though they may share the same switches, cables, and access points.
VLANs are configured on managed switches and operate at Layer 2 (Data Link Layer) of the OSI model. The switch tags each Ethernet frame with a VLAN ID (VID) — a 12-bit field in the IEEE 802.1Q tag header — allowing the switch to enforce separation between VLAN members. Inter-VLAN routing requires a Layer 3 device (router or Layer 3 switch) and is deliberate and policy-controlled.
switchport mode access + switchport access vlan [ID]switchport mode trunk + switchport trunk allowed vlan [list]The following diagram shows a typical small-business VLAN deployment. All devices connect to the same physical switch but are logically separated into four VLANs. A router (or Layer 3 switch) handles inter-VLAN routing and enforces firewall rules between segments.
Native VLAN
On a trunk port, the native VLAN is the VLAN whose traffic is sent untagged. When a frame arrives on a trunk port with no 802.1Q tag, the switch assigns it to the native VLAN. By default this is VLAN 1 on Cisco equipment. Mismatched native VLANs on trunk ports can cause subtle connectivity issues and are a security concern (VLAN hopping attacks exploit native VLAN mismatches). Best practice: change the native VLAN from VLAN 1 to an unused VLAN and use a dedicated management VLAN.
Exam Focus — VLANs
VLANs operate at Layer 2 and create separate broadcast domains. The IEEE standard for VLAN tagging is 802.1Q. Access ports carry one VLAN for end devices; trunk ports carry multiple VLANs between switches. Inter-VLAN routing requires a Layer 3 device (router or L3 switch). A question about isolating guest Wi-Fi from corporate traffic → VLANs. A question about reducing broadcast traffic on a large flat network → VLANs.
A VPN (Virtual Private Network) creates a secure, encrypted communications tunnel over an untrusted public network — typically the internet. The VPN allows a remote device to communicate as if it were physically connected to the private network, with all traffic encrypted and unreadable to anyone intercepting it on the path between the client and the VPN server.
From the user's perspective, a VPN makes their device appear to be "inside" the corporate network, on the home network, or in a different geographic location. From the network's perspective, the VPN creates a logical point-to-point connection between two endpoints that routes all traffic through an encrypted tunnel, regardless of the physical path the packets take across the internet.
Why VPNs Are Essential
Public networks — hotel Wi-Fi, airport networks, coffee shop hotspots — are untrusted environments where attackers can potentially intercept unencrypted traffic. A VPN encrypts all traffic leaving the device before it enters the public network, so even if an attacker captures every packet, they see only encrypted ciphertext. VPNs also allow remote workers to access internal corporate resources (file servers, printers, internal web applications) that are not exposed to the public internet.
Exam Focus — VPN
A VPN creates an encrypted tunnel over an untrusted public network. Remote access VPN = one user to one site (client-to-site). Site-to-site VPN = two networks connected permanently. Split tunneling = corporate traffic goes through VPN; internet traffic goes direct. IPsec operates at Layer 3; SSL VPN uses port 443 (TLS/HTTPS). PPTP is insecure — the A+ exam treats it as deprecated. VPN concentrator = the enterprise device that terminates VPN connections at the network edge.
| Protocol | Layer | Port(s) | Encryption | Status |
|---|---|---|---|---|
| PPTP | Layer 2 | TCP 1723 | Weak (MS-CHAPv2) | ⛔ Deprecated / insecure |
| L2TP/IPsec | Layer 2 + 3 | UDP 1701, 500, 4500 | IPsec (AES) | ✅ Acceptable; being replaced |
| IPsec (IKEv2) | Layer 3 | UDP 500, 4500 | AES (configurable) | ✅ Standard enterprise choice |
| SSL/TLS (OpenVPN) | Layer 4–7 | TCP/UDP 443 or 1194 | TLS (AES) | ✅ Best firewall traversal |
| WireGuard | Layer 3 | UDP 51820 | ChaCha20 / AES | ✅ Modern; fast; simple |
Final Exam Reminders
A record = IPv4; AAAA record = IPv6; CNAME = alias to another hostname (never an IP directly); MX = mail server (lower priority number = tried first).
SPF, DKIM, DMARC are all DNS TXT records used for email authentication. SPF = authorized IPs. DKIM = cryptographic signature. DMARC = policy enforcement (none / quarantine / reject) + reporting.
DHCP DORA = Discover (broadcast) → Offer → Request (broadcast) → Acknowledge. The client discovers and requests via broadcast because it has no IP address yet.
APIPA = 169.254.x.x — always means DHCP failed. Follow up with ipconfig /release then ipconfig /renew.
Exclusion = never assign this address to anyone. Reservation = always assign this address to this specific MAC address.
VLANs work at Layer 2, use 802.1Q tagging, reduce broadcast domains, and require Layer 3 routing (router or L3 switch) for inter-VLAN communication. Access port = one VLAN. Trunk port = many VLANs.
VPN = encrypted tunnel over untrusted network. Remote access = user to site. Site-to-site = network to network. Split tunneling = only corporate traffic in VPN. PPTP = insecure and deprecated.
SSL VPN advantage: runs on TCP 443 (HTTPS) and traverses virtually all firewalls without special configuration — ideal when corporate VPN must work from restrictive networks.