DNS troubleshooting appears consistently on the CompTIA Network+ exam. The scenarios test whether you can identify the cause of name resolution failure, choose the right diagnostic tool, and understand what each DNS record type does.
What DNS Does
DNS (Domain Name System) translates human-readable domain names (www.example.com) into IP addresses that computers use to route traffic. Without DNS, you would need to memorise IP addresses for every resource you want to reach.
DNS Record Types
| Record Type | Purpose |
|---|---|
| A | Maps a hostname to an IPv4 address |
| AAAA | Maps a hostname to an IPv6 address |
| CNAME | Canonical Name — creates an alias from one name to another |
| MX | Mail Exchanger — specifies the mail server for a domain |
| PTR | Pointer — reverse DNS lookup (IP address to hostname) |
| NS | Name Server — identifies the authoritative DNS servers for a domain |
| SOA | Start of Authority — administrative info about the zone |
| TXT | Text record — used for domain verification and email authentication (SPF, DKIM) |
| SRV | Service record — specifies the location of specific services |
Exam scenarios:
"Email sent to the domain is not being delivered. Which DNS record should be checked?" — MX record.
"A company wants to map mail.example.com to the same IP as server.example.com." — CNAME record pointing mail.example.com to server.example.com.
"An administrator wants to verify that an IP address resolves to the correct hostname." — PTR record (reverse DNS).
Diagnostic Tools
nslookup — The primary DNS diagnostic tool. Queries DNS servers to look up records:
nslookup www.example.com
nslookup -type=MX example.com
nslookup www.example.com 8.8.8.8
The last example queries a specific DNS server (8.8.8.8 = Google DNS). This is useful for testing whether the problem is with your DNS server specifically or a universal DNS issue.
dig — Similar to nslookup, available on Linux/macOS, provides more detailed output. Used in exam scenarios for Linux environments.
ipconfig /flushdns — Clears the local DNS cache on Windows. Use when a recently changed DNS record is not being picked up.
ipconfig /displaydns — Shows the current contents of the local DNS cache.
Common DNS Failure Scenarios
Scenario 1: Can ping by IP, cannot ping by name
This is a DNS resolution failure — network connectivity is fine. Causes:
- Wrong DNS server configured (check
ipconfig /all) - DNS server is down
- The DNS record does not exist
- Cached incorrect record (try
ipconfig /flushdns)
Scenario 2: Internal resources resolve, internet resources do not
The DNS server can resolve internal names but not forward external queries. Causes:
- DNS forwarder not configured
- DNS server has no internet connectivity
- Firewall blocking DNS traffic (UDP/TCP port 53) from the DNS server
Scenario 3: DNS resolution intermittently fails
- DNS server overloaded or intermittently reachable
- DHCP assigning incorrect DNS server IPs
- DNS TTL causing stale records to be served from cache
HOSTS File
The HOSTS file (C:\Windows\System32\drivers\etc\hosts on Windows) is checked before DNS queries. Entries in the HOSTS file override DNS.
Exam trap: "A user can access a website from other computers but gets an error on their workstation. DNS resolves correctly when tested from another machine." — Check the HOSTS file on the affected workstation. It may have an incorrect or malicious entry overriding the DNS record.
DNS Port
DNS uses port 53 on both UDP (standard queries) and TCP (zone transfers and large responses). Firewall rules must allow port 53.
Practice Network+ DNS troubleshooting questions to build recognition of these failure patterns.
nslookup Deep Dive — Flags and Switches the Exam Tests
nslookup works in two modes. Non-interactive mode is a single query run directly from the command line:
nslookup google.com
nslookup -type=MX google.com
nslookup -type=MX google.com 8.8.8.8
The third example specifies an alternate DNS server (8.8.8.8) instead of the system's configured resolver. This is useful for troubleshooting: if nslookup google.com fails against your local resolver but works against 8.8.8.8, the problem is your local DNS server, not the record itself.
Interactive mode starts with just nslookup and gives a > prompt where you can run multiple queries:
> server 8.8.8.8 (switch to a specific DNS server)
> set type=MX (query MX records instead of A records)
> google.com (query using the configured type)
> set type=NS (switch to NS records)
> set debug (show detailed response information)
The exam tests "non-authoritative answer" — what it means and when you see it. An authoritative answer comes directly from the DNS server that holds the zone file (the authoritative nameserver for the domain). A non-authoritative answer comes from a resolver that retrieved the answer from cache or from the authoritative server on your behalf. Almost every nslookup result you'll see in practice is non-authoritative, because you're querying a recursive resolver, not the authoritative server directly.
To query the authoritative server directly: first find the NS record for the domain, then query one of those nameservers explicitly using nslookup domainname nsserver. The answer from the authoritative server itself will not say "Non-authoritative answer."
DNS Hierarchy — Root → TLD → Authoritative
Understanding the full resolution path helps with troubleshooting questions that ask "at which step is the query failing?"
When your computer queries for mail.company.com and there's no cached answer:
- Your OS sends the query to the recursive resolver (your configured DNS server — usually your ISP's or 8.8.8.8).
- The resolver has no cache entry and queries a root server (`. zone) asking "who handles .com?"
- Root server returns the .com TLD nameservers.
- Resolver queries the .com TLD nameserver asking "who handles company.com?"
- TLD returns company.com's authoritative nameservers.
- Resolver queries the authoritative nameserver for company.com directly.
- Authoritative server returns the A record for mail.company.com.
- Resolver caches the result and returns it to your computer.
Recursive query — your computer asks the resolver to do all the work and return a final answer. That's what your client sends.
Iterative query — the resolver asks each server in the chain individually, gets referrals, and does the next query itself. That's what happens between servers.
Root hints are the list of root server IPs that resolvers have hardcoded. Windows DNS Server caches them in a file; Linux resolvers ship with them in the package. Root hints are how the entire DNS hierarchy bootstraps.
Split-Brain DNS — Internal vs External Resolution
Split-brain (also called split-horizon) DNS means the same domain name resolves to different IP addresses depending on where the query originates.
Typical setup: intranet.company.com resolves to 10.1.1.50 (private IP) for queries from inside the office network, but resolves to 203.0.113.10 (public IP) for queries from the internet. The internal DNS server has an A record with the private IP. External DNS (registered with the public DNS provider) has the public IP.
This works fine for users in the office — their DNS queries go to the internal server and get the private IP, which routes correctly on the internal network. But remote workers who aren't on VPN query public DNS, get the public IP, and might reach a different path or fail if the public IP isn't configured for that service.
Exam scenario: "Users in the office can reach intranet.company.com but users working from home cannot. No firewall changes have been made recently." → Split-brain DNS is configured; remote users get the public IP (which may not be routable or may be a different server). Resolution: either require VPN for remote access so they use internal DNS, or add a public DNS record pointing to the correct public endpoint.
DNS Security — DNSSEC, DoH, DoT
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. When a resolver receives a record, it can verify the digital signature to confirm the record is authentic and wasn't tampered with in transit. This prevents DNS cache poisoning (also called DNS spoofing), where an attacker injects false records into a resolver's cache.
DNSSEC does not encrypt the query — it only signs the response for authentication. Queries and responses are still visible to anyone who can see the network traffic.
DNS over HTTPS (DoH) sends DNS queries inside HTTPS (port 443). The content of the query is encrypted and looks like ordinary HTTPS traffic. Prevents eavesdropping on DNS queries and makes DNS traffic indistinguishable from web traffic (bypasses some DNS-based content filters).
DNS over TLS (DoT) sends DNS queries over an encrypted TLS connection on port 853. Similar to DoH in terms of privacy but uses a dedicated port, making it easier for network administrators to identify and control.
Exam mapping:
- "Prevent DNS cache poisoning" → DNSSEC
- "Prevent eavesdropping on DNS queries" → DoH or DoT
- "Prevent a man-in-the-middle from injecting false DNS responses" → DNSSEC
Common DNS Failure Scenarios
Wrong IP in A record — Usually a stale record after a server IP change. The old IP is still cached or the record wasn't updated. Test with nslookup to see what's being returned, compare to actual server IP. Fix: update the A record, wait for TTL to expire from caches.
MX record points to a CNAME — RFC 5321 prohibits MX records pointing to CNAMEs. Many DNS providers still accept the configuration but email delivery will fail unpredictably. MX records must point directly to A records. To fix: create an A record for the mail server hostname, point the MX record to that A record directly.
TTL too high after a planned change — If you're about to change a record (migrate a server, change IP), lower the TTL to 300 seconds (5 minutes) 24–48 hours before the change. After the old TTL expires from all caches, make the change. The 5-minute TTL means the transition is fast. Then raise TTL back after the migration is stable.
Negative caching — Failed lookups are also cached, for the duration of the SOA record's minimum TTL. If you query a record that doesn't exist, your resolver caches the "NXDOMAIN" response. Creating the record on the DNS server doesn't immediately fix the client — the negative cache must expire first.
Before Exam Day — What to Know Cold
- nslookup syntax to query each record type (
-type=A,-type=MX,-type=CNAME,-type=TXT,-type=NS,-type=SOA) - "Non-authoritative answer" = cached response from recursive resolver (not a problem, just informational)
- All 8 DNS record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (nameserver), PTR (reverse lookup), SOA (zone authority), TXT (text, SPF/DKIM/DMARC)
- DNSSEC = authentication/integrity, not encryption
- DoH uses port 443, DoT uses port 853
- Split-brain DNS = different answers inside vs outside the network