This chapter covers DNS resolution issues, a critical troubleshooting topic for the CompTIA A+ Core 1 (220-1101) exam under Objective 5.4. DNS is fundamental to network connectivity; without proper resolution, users cannot access websites, email, or cloud services. Expect approximately 5-8% of exam questions to touch on DNS troubleshooting, often in scenario-based items where you must identify the root cause of a name resolution failure. Mastering this topic requires understanding the DNS resolution process, common failure points, and the tools used to diagnose and fix issues.
Jump to a section
Imagine a large office building where every person has a direct internal phone number, but to call someone outside the building, you need to look up their company's main switchboard number in a giant phone directory. That directory is the DNS. When you want to call a company, you look up the name (like 'Acme Corp') in the directory, and it gives you the main number (the IP address). If the directory is missing the listing, you can't call at all. If the listing is wrong, you dial the wrong number. The directory is organized hierarchically: top-level (like country codes), then regional, then local. Your phone might cache recent lookups so you don't have to check the directory every time. But if the cache is stale, you might call an old number. DNS works exactly like this: your computer asks a resolver (like your local IT help desk) to look up a domain name, which then queries root servers (like international directory assistance), then TLD servers (like country-specific directories), then authoritative servers (like the company's own phone list). The resolver caches the result for a time (TTL). If anything in the chain fails or is misconfigured, the lookup fails or returns wrong data.
What is DNS Resolution?
DNS (Domain Name System) resolution is the process of converting a human-readable domain name (e.g., www.example.com) into a machine-readable IP address (e.g., 192.0.2.1). This is essential because network devices communicate using IP addresses, but users remember names. DNS is a hierarchical, distributed database that uses a client-server model. The client (stub resolver) sends queries to a DNS resolver (typically provided by the ISP or a public resolver like 8.8.8.8), which then recursively queries authoritative servers to find the answer.
How DNS Resolution Works Internally
When a user types a URL into a browser, the following steps occur at the protocol level: 1. The application (e.g., web browser) calls the operating system's resolver library (e.g., gethostbyname or getaddrinfo). 2. The resolver checks its local DNS cache (stored in memory) for the name. If found and not expired, it returns the IP immediately. 3. If not cached, the resolver sends a UDP query to the configured DNS server (usually on port 53). The query is a DNS request packet containing the domain name and record type (e.g., A record for IPv4, AAAA for IPv6). 4. The configured DNS server (recursive resolver) receives the query. If it has the answer cached, it returns it. Otherwise, it begins recursive resolution:
- It queries a root server (e.g., 198.41.0.4) to find the TLD server (e.g., for .com). - It then queries the TLD server (e.g., 192.5.6.30) to get the authoritative name server for example.com. - Finally, it queries the authoritative name server (e.g., 192.0.2.1) for the specific record. 5. The recursive resolver caches the result based on the Time-To-Live (TTL) value in the DNS response (typically 300-86400 seconds). 6. The resolver returns the IP address to the client's operating system, which caches it locally and passes it to the application. 7. The application then initiates a TCP connection to that IP address.
Key Components, Values, and Timers
Stub Resolver: The client-side DNS resolver built into the OS. It typically has a small cache (e.g., Windows DNS Cache size is 256 KB by default, but can grow).
Recursive Resolver: The server that performs full resolution on behalf of clients. Common examples: ISP resolvers, Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
Root Servers: 13 logical root servers (named A through M), operated by various organizations. They answer with referrals to TLD servers.
TLD Servers: Authoritative for top-level domains like .com, .org, .net, .gov, etc.
Authoritative Name Server: The final source of truth for a domain. It holds DNS records (A, AAAA, CNAME, MX, NS, etc.).
TTL (Time-To-Live): A 32-bit integer in seconds that tells resolvers how long to cache the record. Common values: 300 (5 min) for dynamic content, 86400 (24 hours) for stable records. Exam tip: Low TTLs cause more queries but allow faster updates; high TTLs reduce load but delay propagation.
DNS Cache: Temporary storage of DNS query results. On Windows, view with ipconfig /displaydns; clear with ipconfig /flushdns. On Linux/macOS, use sudo dscacheutil -flushcache (macOS) or sudo systemd-resolve --flush-caches (Linux with systemd-resolved).
DNS Records: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail exchange), NS (name server), PTR (reverse lookup), SOA (start of authority), TXT (text, often used for SPF, DKIM).
Default Ports: DNS uses UDP port 53 for queries and responses (max 512 bytes). If the response is larger (e.g., DNSSEC), it falls back to TCP port 53. Zone transfers use TCP.
DNS Timeout: The resolver typically waits 5-10 seconds for a response before retrying. After 3-5 retries, it returns an error (e.g., "DNS server not responding").
Configuration and Verification Commands
- Windows:
- ipconfig /all – Shows configured DNS servers.
- nslookup – Interactive or one-shot DNS lookup. Example: nslookup www.example.com 8.8.8.8 uses a specific resolver.
- nslookup -type=MX example.com – Query MX records.
- ping -n 1 www.example.com – Tests name resolution indirectly.
- tracert www.example.com – Traces route; fails if DNS fails.
- Linux/macOS:
- dig www.example.com – Detailed DNS query output.
- dig +short www.example.com – Returns only IP.
- nslookup (also available on Linux).
- host www.example.com – Simple lookup.
- cat /etc/resolv.conf – Shows configured DNS servers.
- Common DNS Record Types to Know for Exam:
A: Maps hostname to IPv4.
AAAA: Maps hostname to IPv6.
CNAME: Alias (canonical name) – maps one name to another. Example: www.example.com CNAME to example.com.
MX: Mail exchanger – priority and hostname.
NS: Authoritative name server for the domain.
PTR: Reverse mapping from IP to hostname.
SOA: Start of authority – primary name server, admin email, serial number, refresh/retry/expire/TTL values.
How DNS Interacts with Related Technologies
DHCP: Often automatically assigns DNS server addresses via DHCP options (e.g., option 6 for DNS servers). Misconfigured DHCP can result in wrong DNS servers.
Firewalls: Must allow UDP/TCP port 53 to/from the DNS server. Many corporate firewalls block outbound DNS except to specific resolvers.
VPN: VPN clients may push DNS servers that resolve internal domain names. Split tunneling can cause DNS leaks or failures.
IPv6: DNS queries for AAAA records; if IPv6 is not fully functional, the client may time out waiting for an AAAA response. Some systems try AAAA first (RFC 3484), causing delays if IPv6 is broken.
DNSSEC: Adds cryptographic signatures to DNS records to prevent spoofing. Validating resolvers check signatures; failure can cause SERVFAIL.
Hosts File: A static file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux/macOS) that overrides DNS. Entries here take precedence. Malware often modifies this file.
NetBIOS/LLMNR: Fallback name resolution methods on Windows. If DNS fails, Windows may try NetBIOS (broadcast) or LLMNR (link-local multicast). These can be exploited (e.g., Responder attacks).
Common DNS Issues and Root Causes
DNS Server Not Responding: The configured DNS server is unreachable (network issue, server down, firewall blocking). Symptom: nslookup returns "DNS request timed out."
Wrong DNS Server: The client is configured with an incorrect or malicious DNS server. Symptom: resolution returns wrong IP or fails.
DNS Cache Poisoning: Corrupted cache with incorrect mappings. Symptom: intermittent failures or redirected traffic. Flush cache to resolve.
Incorrect Hosts File Entry: Static entry pointing to wrong IP. Symptom: consistent failure for that hostname.
Missing DNS Record: The domain does not have the requested record (e.g., no A record for a hostname). Symptom: nslookup returns "Non-existent domain" (NXDOMAIN).
TTL Issues: Stale cache after DNS record change. Symptom: some users get old IP, others new IP until TTL expires.
DNSSEC Validation Failure: If DNSSEC is enabled and the chain of trust is broken, the resolver returns SERVFAIL.
Recursion Not Allowed: Some DNS servers (especially authoritative) do not allow recursive queries from arbitrary clients. Symptom: nslookup returns "*** UnKnown" or "query refused."
MTU/Path MTU Issues: DNS over UDP may fail if the response exceeds the path MTU and fragmentation is blocked. Fallback to TCP may fail if blocked.
IPv6 vs IPv4 Preference: If the client prefers IPv6 but the DNS server only returns an AAAA record that is unreachable, the connection may hang.
Check Network Connectivity
Before blaming DNS, ensure the client has basic network connectivity. Ping the configured DNS server's IP address directly. For example, if DNS is 8.8.8.8, run `ping 8.8.8.8`. If ping fails, the issue is network-level (cable, Wi-Fi, DHCP, default gateway). Also check if other IP-based services work (e.g., ping 1.1.1.1). If you can ping the DNS server but not resolve names, the problem is likely DNS-specific. On Windows, use `ipconfig /all` to verify the DNS server IP is correct.
Verify DNS Server Configuration
Check the client's DNS settings. On Windows, run `ipconfig /all` and look for "DNS Servers." Ensure the IP addresses are correct. Common mistakes: using an internal DNS server that is not reachable from the current network, or using a public DNS like 8.8.8.8 when corporate policy requires internal resolution. On Linux, check `/etc/resolv.conf`. If using DHCP, verify the DHCP server is providing correct DNS options. Also check for multiple DNS servers; the client will try them in order.
Test with nslookup or dig
Use `nslookup` (Windows/Linux) or `dig` (Linux/macOS) to perform a manual DNS query. For example, `nslookup www.example.com` will use the default resolver. To test a specific DNS server, use `nslookup www.example.com 8.8.8.8`. If this succeeds but the default fails, the issue is with the configured DNS server. If both fail, the problem may be with the domain itself or upstream DNS. Look for error messages: "Non-existent domain" (NXDOMAIN) means the record doesn't exist; "server failed" (SERVFAIL) indicates a server error; "query refused" means recursion denied.
Flush Local DNS Cache
Corrupted or stale DNS cache can cause resolution failures. On Windows, run `ipconfig /flushdns` as Administrator. On macOS, run `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`. On Linux with systemd-resolved, `sudo systemd-resolve --flush-caches`. After flushing, retry the lookup. If the problem was cache-related, it should now work. Also consider clearing the browser's DNS cache (chrome://net-internals/#dns) and the hosts file.
Check Hosts File and Local Overrides
The hosts file can override DNS. On Windows, it's at `C:\Windows\System32\drivers\etc\hosts`. On Linux/macOS, it's `/etc/hosts`. Open it in a text editor (requires admin privileges) and look for entries related to the problematic domain. Malware often adds entries to redirect traffic. Also check for any proxy settings that might interfere (e.g., system proxy or PAC files). A common exam scenario: a user cannot access a website, and the hosts file has an incorrect entry pointing to 127.0.0.1 or a wrong IP.
Test with Alternate DNS Server
Temporarily change the client's DNS server to a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1). If resolution works with the alternate server, the issue is with the original DNS server (e.g., ISP DNS outage, misconfiguration, or filtering). On Windows, go to Network and Sharing Center > Change adapter settings > right-click adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties > Use the following DNS server addresses. On Linux, edit `/etc/resolv.conf` (temporary) or use `nmcli` for NetworkManager.
Check Firewall and Security Software
Firewalls or security software may block DNS queries. Temporarily disable the firewall (if safe) to test. Also check for DNS filtering or content filtering that might block certain domains. Corporate networks often use web proxies that intercept DNS; ensure the proxy settings are correct. Some malware modifies DNS settings in the registry or uses a fake DNS server. Run a security scan if suspicious.
Enterprise Scenario 1: Internal DNS Resolution for Corporate Network
A large enterprise uses Active Directory with internal DNS servers (e.g., 10.0.0.1 and 10.0.0.2) that resolve internal hostnames (e.g., file-server.company.local) and forward external queries to ISP DNS. A user reports being unable to access internal file shares by name. Troubleshooting: First, ping the file server IP (10.1.1.10) – succeeds. Then nslookup file-server.company.local returns "Non-existent domain." Check the DNS zone: the record was accidentally deleted. The administrator adds the A record and increments the SOA serial number. The user clears cache and resolves successfully. Common scale: hundreds of clients; TTL set to 15 minutes to reduce load. Misconfiguration: If the forwarder is set incorrectly (e.g., to a public DNS that doesn't resolve internal names), internal lookups fail. Solution: ensure internal zones are authoritative and forwarders are only for external domains.
Enterprise Scenario 2: Public Website Migration
A company migrates its website from IP 203.0.113.10 to 198.51.100.20. They update the A record on their authoritative DNS provider. After 24 hours, some customers still reach the old server. This is due to TTL: the old record had a TTL of 86400 (24 hours). Customers' ISPs still have the old record cached. The administrator reduces TTL to 300 before the migration, then after migration, sets it back to 86400. Also, some customers may use public resolvers (e.g., 8.8.8.8) that cache longer. The administrator uses dig to check propagation: dig www.example.com +trace shows the new IP. For immediate flush, they can ask users to flush their DNS cache or use a web proxy. Common mistake: not lowering TTL before the change leads to extended downtime.
Enterprise Scenario 3: DNS Filtering and Security
A school uses OpenDNS (208.67.222.222) for content filtering. A teacher reports that a legitimate educational website is blocked. The administrator checks the OpenDNS dashboard and finds the domain is miscategorized. They request re-categorization. Meanwhile, they can whitelist the domain. Alternatively, they can bypass filtering by using a different DNS server for that specific client, but that defeats security. The administrator also ensures that local DNS cache is not poisoned by malware. They run ipconfig /displaydns and look for suspicious entries. They also check the hosts file for malicious redirects. In production, DNS filtering is common for compliance and security, but it requires careful management of whitelists and category updates.
What the 220-1101 Exam Tests on DNS Resolution Issues
Objective 5.4: "Given a scenario, troubleshoot common DNS issues." The exam focuses on identifying the cause of name resolution failures and applying appropriate fixes. You must know the tools (nslookup, ipconfig /flushdns, ipconfig /displaydns, ping) and when to use them. Common scenarios: a user cannot access a website, but can ping the IP; a user gets redirected to a wrong site; a user gets "DNS server not responding." You must differentiate between DNS issues and other network problems.
Common Wrong Answers and Why Candidates Choose Them
"The DNS server is down" – Often chosen when nslookup times out. But the exam might describe a scenario where the DNS server is reachable (ping works) but returns wrong results. The correct answer might be "DNS cache corruption" or "hosts file misconfiguration." Candidates jump to server down because it's a common real-world issue, but the exam tests more subtle problems.
"The domain is expired" – Chosen when nslookup returns NXDOMAIN. However, NXDOMAIN can also mean the specific hostname doesn't exist (e.g., typo in URL). The exam expects you to verify the exact hostname and record type.
"Need to renew IP address" – Candidates confuse DHCP issues with DNS. If the client has an IP but cannot resolve names, ipconfig /renew won't help unless the DNS server address was wrong.
"The DNS cache needs to be flushed" – This is a valid fix for stale entries, but sometimes the underlying issue is a persistent incorrect hosts file entry. The exam may present a scenario where flushing cache doesn't work, and the correct answer is to check the hosts file.
Specific Numbers and Terms That Appear on the Exam
Default DNS port: 53 (UDP and TCP).
Common public DNS: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 208.67.222.222 (OpenDNS).
TTL: A value in seconds; exam may ask about the effect of low vs. high TTL.
Record types: A, AAAA, CNAME, MX, NS, PTR, SOA, TXT.
Hosts file location: C:\Windows\System32\drivers\etc\hosts (Windows), /etc/hosts (Linux/macOS).
Flush command: ipconfig /flushdns (Windows), sudo dscacheutil -flushcache (macOS).
nslookup options: -type=MX, -type=NS, etc.
Edge Cases and Exceptions the Exam Loves
IPv6 DNS (AAAA records): If the client prefers IPv6 but the AAAA record points to an unreachable address, the connection may hang. The fix might be to disable IPv6 or ensure IPv6 connectivity.
Split DNS: Internal and external DNS return different IPs for the same name. The exam might test that internal users should use internal DNS servers.
DNSSEC: If DNSSEC validation fails, the resolver returns SERVFAIL. The exam may ask why a domain is unreachable even though it exists.
CNAME at apex: A CNAME record cannot coexist with other records at the domain root. The exam may test that this configuration is invalid.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If the user can access the site by IP but not by name, the problem is definitely DNS (not network connectivity). Eliminate any answer about cable, Wi-Fi, or IP configuration.
If nslookup returns an IP but the browser fails, the problem is likely at the application layer (e.g., proxy, HTTPS certificate). Eliminate DNS-specific answers.
If nslookup returns a different IP than expected, suspect cache poisoning or hosts file. Flush cache first, then check hosts file.
If nslookup returns "Non-existent domain," check for typos or missing records. The domain itself may be valid but the specific hostname is not.
DNS translates domain names to IP addresses; failure results in inability to access resources by name.
The default DNS port is 53 (UDP and TCP).
Common DNS record types for the exam: A, AAAA, CNAME, MX, NS, PTR, SOA, TXT.
Flush DNS cache with `ipconfig /flushdns` (Windows) or `sudo dscacheutil -flushcache` (macOS).
The hosts file overrides DNS; check it when resolution fails unexpectedly.
TTL determines how long DNS records are cached; low TTL means faster propagation but more queries.
Public DNS servers: Google (8.8.8.8), Cloudflare (1.1.1.1), OpenDNS (208.67.222.222).
nslookup and dig are primary troubleshooting tools; use them to test resolution against specific servers.
NXDOMAIN means the domain does not exist; SERVFAIL indicates a server error.
Firewalls must allow UDP and TCP port 53 for DNS to work correctly.
These come up on the exam all the time. Here's how to tell them apart.
nslookup
Available on Windows, Linux, and macOS.
Interactive mode by default; can be used non-interactively.
Less verbose output; easier for quick checks.
Can specify a different DNS server inline: nslookup domain server
May not show all record types in detail (e.g., CNAME chain).
dig
Primarily used on Linux/macOS; available on Windows via BIND tools.
Non-interactive by default; more detailed output.
Shows full DNS response including flags, authority, and additional sections.
Syntax: dig @server domain type (e.g., dig @8.8.8.8 example.com MX).
Supports +trace to show iterative resolution steps.
Mistake
DNS only uses UDP port 53.
Correct
DNS primarily uses UDP, but TCP port 53 is used for responses larger than 512 bytes (e.g., DNSSEC) and for zone transfers. Many firewalls block TCP 53, causing intermittent failures for large responses.
Mistake
Flushing the DNS cache will fix all DNS problems.
Correct
Flushing only clears cached entries. If the problem is a misconfigured hosts file, wrong DNS server, or network issue, flushing does nothing. It is a first step, not a panacea.
Mistake
The DNS server is down if nslookup times out.
Correct
Timeout can also be caused by firewall blocking port 53, network congestion, or the client's own firewall. Always ping the DNS server IP first to verify reachability.
Mistake
A CNAME record can be used at the domain apex (e.g., example.com).
Correct
The DNS specification (RFC 1034) prohibits CNAME records at the apex because it conflicts with other required records (SOA, NS). To alias the apex, use a web redirect or ALIAS/ANAME record (not standard DNS).
Mistake
DNS resolution always starts with a query to a root server.
Correct
The recursive resolver may have the answer cached, so it may not query root servers at all. Only the first query for a domain after TTL expiry triggers a full recursive lookup.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This indicates a DNS resolution issue. Your computer can communicate on the network (since ping to IP works), but it cannot translate the domain name to an IP. Possible causes: incorrect DNS server configuration, DNS server unreachable, corrupted DNS cache, hosts file misconfiguration, or the domain name does not exist. Use `nslookup` to test resolution. If nslookup fails, check DNS settings with `ipconfig /all`, flush the cache, and verify the hosts file.
An A record maps a hostname to an IPv4 address (e.g., 192.0.2.1). An AAAA record maps a hostname to an IPv6 address (e.g., 2001:db8::1). If a client has both IPv4 and IPv6 connectivity, it may request both record types. If the AAAA record exists but IPv6 connectivity is broken, the client may experience delays or failures. The exam may test that some systems prefer IPv6 over IPv4 (RFC 3484).
Open Command Prompt as Administrator and run `ipconfig /flushdns`. This clears the local DNS resolver cache. After flushing, you can verify with `ipconfig /displaydns` to see the cache is empty. On macOS, use `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`. On Linux with systemd-resolved, use `sudo systemd-resolve --flush-caches`.
NXDOMAIN (Non-Existent Domain) means the DNS server could not find the requested domain name. This could be because the domain does not exist, the hostname is misspelled, or the record type is missing. For example, querying an A record for a hostname that only has a CNAME might return NXDOMAIN if the CNAME target does not exist. Always verify the exact domain and record type.
Yes. Firewalls must allow outbound UDP and TCP traffic on port 53 to DNS servers. Some corporate firewalls block DNS to prevent data exfiltration or enforce filtering. If you cannot resolve names but can ping IPs, check firewall rules. Also, some security software may intercept DNS and cause issues. Temporarily disable the firewall for testing (with caution).
The hosts file is a static text file that maps hostnames to IP addresses. It is checked before DNS resolution. If an entry exists for a domain, the OS uses that IP without querying DNS. This can be useful for testing or blocking websites, but malware often modifies it to redirect traffic. On Windows, it is located at `C:\Windows\System32\drivers\etc\hosts`. On Linux/macOS, it is `/etc/hosts`.
This is often due to DNS caching. Different ISPs and resolvers cache DNS records for different durations (TTL). If you recently changed your website's IP, users whose resolvers still have the old cached IP will go to the old server. Lowering the TTL before the change helps. Also, some users may have stale local cache; they can flush it. Another cause: geographic load balancing or CDN may serve different IPs.
You've just covered Troubleshoot: DNS Resolution Issues — now see how well it sticks with free 220-1101 practice questions. Full explanations included, no account needed.
Done with this chapter?