This chapter covers DNS troubleshooting using nslookup and dig, two essential command-line tools for diagnosing name resolution issues. For the N10-009 exam, DNS troubleshooting questions appear in roughly 5-8% of the Network Troubleshooting domain (Objective 5.3). Mastering these tools is critical because DNS failures are among the most common network problems, and the exam tests your ability to interpret their output to isolate faults between client, resolver, and authoritative servers.
Jump to a section
Imagine you walk into a massive library (the internet) and need to find a specific book (a web server). The library has a card catalog (the DNS system) that maps book titles (domain names) to shelf locations (IP addresses). You approach a librarian (a recursive resolver) and ask for the location of 'Network+ Guide.' The librarian doesn't know every book's location by heart, so she checks her own index (cache). If not found, she consults a master catalog (root server) that tells her which section catalog (TLD server) handles 'Guide' books. She then asks that section catalog, which points her to the specific library branch (authoritative nameserver) that has the exact shelf location. The librarian returns to you with the location (IP address). In this analogy, 'nslookup' and 'dig' are like you asking the librarian directly for the location and also asking to see the step-by-step path she took to find it. If the librarian gives a wrong location, you can use these tools to trace where the error occurred—whether the master catalog, section catalog, or branch gave incorrect information.
What Are nslookup and dig?
nslookup (name server lookup) and dig (domain information groper) are command-line utilities used to query DNS servers and retrieve DNS records. Both are available on Windows, Linux, and macOS, though nslookup is the traditional tool on Windows, while dig is more powerful and widely used on Unix-like systems. The N10-009 exam expects you to know both, their common options, and how to interpret their output.
Why They Exist: DNS is a distributed database. When a client cannot resolve a hostname, the problem could be in the client's resolver configuration, a local cache, a recursive resolver, or an authoritative nameserver. nslookup and dig allow you to bypass the local resolver and directly query specific DNS servers, isolating where the failure occurs.
How DNS Query Resolution Works (Prerequisite Understanding)
Before diving into the tools, understand the standard DNS query flow:
A client (e.g., a browser) requests resolution of www.example.com.
The stub resolver (part of the OS) checks its local cache. If not found, it sends a recursive query to the configured DNS server (typically the ISP's recursive resolver or a public resolver like 8.8.8.8).
The recursive resolver iteratively queries:
- Root server (returns the TLD server for .com)
- TLD server (returns the authoritative nameserver for example.com)
- Authoritative nameserver (returns the A record for www.example.com)
4. The recursive resolver caches the answer and returns it to the client.
nslookup and dig can simulate this process step-by-step or bypass caching by querying authoritative servers directly.
nslookup: Interactive and Non-Interactive Modes
nslookup operates in two modes:
- Non-interactive: Single query from the command line.
- Interactive: Multiple queries within a session (type nslookup then press Enter).
Basic Syntax (Non-Interactive):
nslookup <hostname> [DNS-server]Example:
nslookup www.example.com 8.8.8.8This queries Google's public DNS for www.example.com.
Output Interpretation:
Server: dns.google
Address: 8.8.8.8
Non-authoritative answer:
Name: www.example.com
Address: 93.184.216.34"Non-authoritative answer" means the response came from a resolver's cache, not the authoritative server.
If the server is authoritative, it will say "Authoritative answer."
Key Options:
- -type=<recordtype>: Query a specific record type (A, AAAA, MX, NS, CNAME, SOA, etc.).
- -port=<port>: Specify a different UDP/TCP port (default 53).
- -timeout=<seconds>: Set query timeout.
Interactive Mode Commands:
- server <IP>: Change the default server for subsequent queries.
- set type=<recordtype>: Set query type.
- ls -d <domain>: List all records in a zone (rarely works due to security restrictions).
Common Troubleshooting with nslookup: 1. Check resolver connectivity:
nslookup google.com 8.8.8.8If timeout, check network connectivity to 8.8.8.8 (firewall, routing). 2. Check authoritative NS:
nslookup -type=NS example.comReturns the nameservers for the domain. 3. Check MX records:
nslookup -type=MX example.com4. Reverse DNS lookup:
nslookup 93.184.216.34Limitations of nslookup: - Uses the system's stub resolver by default, which may cache or alter queries. - Does not show the full resolution path (no trace option). - Output formatting is less flexible than dig. - Some advanced DNS features (DNSSEC, EDNS) are not well supported.
dig: The Swiss Army Knife of DNS Troubleshooting
dig is more powerful and provides detailed output. It is the preferred tool for network engineers.
Basic Syntax:
dig [@server] [name] [type] [options]Example:
dig @8.8.8.8 www.example.com AOutput Breakdown:
; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 www.example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 86400 IN A 93.184.216.34
;; AUTHORITY SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 86400 IN A 199.43.135.53
b.iana-servers.net. 86400 IN A 199.43.133.53
;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 16 14:23:45 EDT 2023
;; MSG SIZE rcvd: 123Key Sections: - Header: Shows status (NOERROR, NXDOMAIN, SERVFAIL, REFUSED) and flags (qr=query response, rd=recursion desired, ra=recursion available, aa=authoritative answer). - QUESTION: The query sent. - ANSWER: The resource records returned. - AUTHORITY: Nameservers authoritative for the domain. - ADDITIONAL: Extra records (e.g., IP addresses of nameservers). - Query time: Round-trip time. - MSG SIZE: Size of the response.
Common dig Options:
- +short: Brief output (just IP address).
- +trace: Simulate the iterative resolution from root to authoritative.
- +noall +answer: Show only the answer section.
- -x <IP>: Reverse DNS lookup.
- +dnssec: Request DNSSEC records.
- +tcp: Force TCP query (useful when UDP is blocked).
- +time=<seconds>: Set timeout.
- +retry=<number>: Set retry count.
Using +trace:
dig +trace www.example.comThis shows each step: root hints, TLD query, authoritative query. It is invaluable for finding where resolution fails.
Example Output Snippet:
; <<>> DiG 9.16.1-Ubuntu <<>> +trace www.example.com
;; global options: +cmd
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
...
;; Received 525 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; Received 407 bytes from 199.43.135.53#53(199.43.135.53) in 12 ms
www.example.com. 86400 IN A 93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(199.43.135.53) in 10 msCommon dig Troubleshooting Scenarios: 1. NXDOMAIN: The domain does not exist. Check for typos or missing DNS records. 2. SERVFAIL: The authoritative server failed to respond. Check server health or network connectivity. 3. REFUSED: The server refused the query (often due to access control). 4. Timeout: No response from the server. Check firewall rules (UDP 53). 5. Wrong IP: The answer may be stale or from a malicious DNS server.
Comparing nslookup and dig for the Exam
| Feature | nslookup | dig |
|---------|----------|-----|
| Default on Windows | Yes | No (must install) |
| Default on Linux/macOS | Yes | Yes |
| Trace capability | No (but set debug shows some info) | +trace |
| DNSSEC support | Limited | Full (+dnssec) |
| Scriptable output | Poor | Excellent (+short, +noall) |
| Reverse lookup | Yes | -x |
| Record type filtering | -type= | [type] |
| Interactive mode | Yes | No (but can be scripted) |
The exam expects you to know both. For most troubleshooting, dig is superior. However, nslookup is still widely used in Windows environments.
DNS Record Types Tested
A: IPv4 address
AAAA: IPv6 address
CNAME: Canonical name (alias)
MX: Mail exchange server
NS: Nameserver
SOA: Start of Authority (primary nameserver, admin email, serial, refresh, retry, expire, minimum TTL)
PTR: Pointer record (reverse DNS)
TXT: Text records (SPF, DKIM, DMARC)
Common DNS Issues and Tool Usage
1. Client cannot resolve a hostname.
- Use nslookup hostname to see if the local resolver works.
- If fails, query a public DNS directly: nslookup hostname 8.8.8.8.
- If that works, the issue is with the local DNS server or its configuration.
2. Wrong IP returned.
- Use dig +trace to see which server provided the answer.
- Check for DNS poisoning or stale cache.
3. Slow resolution.
- Use dig +stats to see query time.
- Compare with different resolvers.
4. Mail delivery issues.
- Use nslookup -type=MX domain or dig domain MX.
5. DNSSEC validation failure.
- Use dig +dnssec domain and check the AD flag.
Identify the Symptom
Determine the exact failure: a browser shows 'Server not found,' an email fails to send, or a ping to a hostname fails. Note the exact hostname and the error message. This step is crucial because different symptoms point to different DNS issues. For example, a 'Server not found' error could be due to a missing A record, a wrong DNS server, or network connectivity. The N10-009 exam often presents a scenario and asks which tool to use first. Always start by verifying the hostname with a simple nslookup or dig query.
Test with Default Resolver
Run `nslookup <hostname>` or `dig <hostname>` without specifying a server. This tests the client's configured DNS resolver. If the query succeeds, the problem is likely not DNS. If it fails with 'Non-existent domain' or timeout, proceed. On the exam, if the question says 'The client can ping the DNS server but cannot resolve names,' this step will confirm whether the resolver is responding. Note the 'Non-authoritative answer' flag—if the resolver returns an answer from cache, it may be stale.
Query a Public DNS Server
Run `nslookup <hostname> 8.8.8.8` or `dig @8.8.8.8 <hostname>`. This bypasses the local resolver. If this succeeds, the issue is with the local DNS server (e.g., misconfigured forwarders, firewall blocking DNS, or server overload). If it fails, the problem is with the domain's authoritative servers or the domain itself. On the exam, this step isolates whether the fault is upstream or downstream. Common wrong answer: candidates think a failure here means the internet is down, but it could be a specific domain issue.
Perform a Trace Query
Run `dig +trace <hostname>`. This shows each step from root to authoritative server. Look for where the chain breaks. Common breakpoints: root servers unreachable (ISP issue), TLD server not responding (registry issue), or authoritative server not responding (domain owner issue). If the trace completes but returns NXDOMAIN, the record truly does not exist. The exam loves to test the +trace option as a way to identify the exact failing server. For example, if the TLD query succeeds but the authoritative query times out, the problem is at the authoritative server.
Check Specific Record Types
If the basic A record works but a service fails (e.g., email), query the specific record: `nslookup -type=MX <domain>` or `dig <domain> MX`. Also check CNAME, NS, and SOA records. For reverse DNS issues, use `nslookup <IP>` or `dig -x <IP>`. The exam may present a scenario where a hostname resolves but mail is not delivered, testing your knowledge of MX records. Always verify that the record type matches the service requirement.
Scenario 1: Enterprise DNS Migration
A large enterprise is migrating from an on-premises DNS server (Windows Server DNS) to a cloud-based DNS service (e.g., AWS Route 53). During the cutover, some users report inability to access internal resources by hostname. The network team uses dig @new-dns-server internal-host.example.com and receives NXDOMAIN. They then use dig +trace internal-host.example.com and see that the authoritative server for example.com is still the old server. The problem: the NS records for the domain still point to the old server. The team updates the NS records at the registrar. They also lower the TTL of the SOA record to 300 seconds during migration to speed up propagation. Post-migration, they verify with dig SOA example.com to confirm the serial number matches the new server. Common scale consideration: thousands of clients may have cached old NS records; the team flushes DNS cache on domain controllers and uses ipconfig /flushdns on workstations.
Scenario 2: ISP DNS Outage
A company's internet access becomes intermittent. Users can access some websites but not others. The IT team uses nslookup google.com and gets a timeout. They then query 8.8.8.8 directly: nslookup google.com 8.8.8.8 succeeds. The problem is the ISP's DNS resolver. They temporarily change the DHCP scope's DNS server option to point to Google's public DNS (8.8.8.8 and 8.8.4.4). They also verify that the firewall allows outbound UDP 53 to those IPs. Performance consideration: public DNS may have higher latency than ISP servers, so they monitor response times with dig +stats. They also set up a secondary internal resolver that forwards to multiple upstream servers for redundancy.
Scenario 3: Phishing Attack via DNS Spoofing
A security analyst notices that a critical banking site resolves to a different IP address. Using dig +dnssec bank.com, they see the AD (authentic data) flag is missing, indicating DNSSEC validation failure. They then use dig +trace bank.com and notice that the answer from the recursive resolver differs from the authoritative answer. They confirm DNS spoofing. Mitigation: they configure the internal DNS server to use DNSSEC validation and block responses that fail validation. They also report the incident. The N10-009 exam may test DNSSEC flags and the use of +dnssec to detect spoofing.
Objective 5.3: Given a scenario, use the appropriate network troubleshooting tool. The N10-009 exam tests your ability to select the right tool (nslookup vs dig) for a given scenario and interpret the output. Key sub-objectives:
Identify common DNS issues: NXDOMAIN, SERVFAIL, REFUSED, timeout.
Use nslookup to query specific record types.
Use dig with +trace to isolate failure points.
Understand the difference between authoritative and non-authoritative answers.
Recognize the flags in dig output: aa, qr, rd, ra.
Common Wrong Answers on the Exam: 1. Choosing nslookup over dig when +trace is needed. Candidates often think nslookup can trace, but it cannot. The exam will present a scenario where you need to see each hop; the correct answer is dig with +trace. 2. Assuming 'Non-authoritative answer' means the answer is wrong. It just means the response came from a cache. The answer may still be correct. Candidates mistakenly think they need to query an authoritative server every time. 3. Using nslookup to check DNSSEC. nslookup has limited DNSSEC support; dig with +dnssec is the correct tool. 4. Misinterpreting SERVFAIL as 'domain does not exist.' SERVFAIL means the server could not process the query due to a server error, not that the domain is missing. NXDOMAIN is the correct status for non-existent domain.
Specific Numbers and Values to Memorize: - Default DNS port: UDP 53 (TCP 53 for zone transfers or large responses). - TTL values: often 300 (5 min) to 86400 (24 hours). Exam may ask how long to wait for propagation. - dig +trace starts from root hints; the root servers are 13 logical servers (a-m.root-servers.net). - SOA record fields: serial, refresh (typically 3600-43200 seconds), retry (1800-7200), expire (604800-1209600), minimum TTL (300-3600).
Edge Cases Tested: - CNAME at zone apex: A CNAME record cannot coexist with other records at the root of a domain (RFC 1912). The exam may test that a CNAME for 'example.com' is invalid. - DNS round-robin: Multiple A records for the same name; dig returns them in random order. - IPv6 AAAA queries: If the client has an IPv6 address but the DNS server returns only A records, the client may still resolve but prefer IPv6 if available. - DNS over HTTPS (DoH): The exam may mention DoH as an alternative, but nslookup and dig do not support it natively.
How to Eliminate Wrong Answers: - If the question asks to trace the resolution path, eliminate any answer that does not include +trace. - If the output shows 'SERVFAIL', the answer that says 'domain does not exist' is wrong. - If the output shows 'Non-authoritative answer', the answer that says 'the server is authoritative' is wrong. - If the question involves DNSSEC, look for dig +dnssec.
nslookup and dig both query DNS servers; dig is more powerful and preferred for troubleshooting.
Use dig +trace to identify exactly where DNS resolution fails in the chain.
Non-authoritative answer means the response came from a cache, not the authoritative server.
DNS status codes: NOERROR (success), NXDOMAIN (domain does not exist), SERVFAIL (server error), REFUSED (query refused).
Default DNS port is UDP 53; TCP 53 is used for zone transfers or responses over 512 bytes.
Common record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (nameserver), SOA (authority), PTR (reverse), TXT (text).
Always verify with a public DNS server (e.g., 8.8.8.8) to isolate local resolver issues.
The +short option in dig returns only the IP address for quick checks.
Reverse DNS lookups use PTR records and are performed with nslookup <IP> or dig -x <IP>.
TTL values affect how long results are cached; lower TTL helps during changes but increases query load.
These come up on the exam all the time. Here's how to tell them apart.
nslookup
Default on Windows; no installation needed.
Interactive mode available.
Limited output; shows only basic answer.
No built-in trace; debug mode is not a full trace.
DNSSEC support is minimal; cannot easily verify AD flag.
dig
Default on Linux/macOS; available on Windows via BIND.
No interactive mode; all queries are single-shot.
Detailed output with sections: HEADER, QUESTION, ANSWER, AUTHORITY, ADDITIONAL.
Supports +trace for full iterative resolution path.
Full DNSSEC support with +dnssec flag; shows AD flag.
Mistake
nslookup and dig are interchangeable for all tasks.
Correct
While both query DNS, dig provides far more detailed output, supports +trace for full resolution path, and is better for scripting. nslookup is simpler but lacks trace and DNSSEC support. The exam expects you to know when to use each.
Mistake
A 'Non-authoritative answer' means the IP address is wrong.
Correct
Non-authoritative merely means the response came from a cache (recursive resolver), not directly from the authoritative server. The IP address can be correct. To get an authoritative answer, query the authoritative nameserver directly.
Mistake
If nslookup returns NXDOMAIN, the domain definitely does not exist.
Correct
NXDOMAIN means the DNS server has no record for that name, but it could be due to a missing record or a misconfigured server. Always verify with dig +trace to see if the authoritative server returns NXDOMAIN or if a middle server is interfering.
Mistake
dig +trace always works and shows the exact path.
Correct
+trace works only if the recursive resolver allows it. Some resolvers block +trace queries. Also, the path shown is from the resolver's perspective; the actual path may differ if the resolver uses anycast or load balancing.
Mistake
nslookup can perform a trace using the debug option.
Correct
The `set debug` command in nslookup shows some internal steps but does not perform a full iterative trace like dig +trace. It shows the query sent to the server and the response, but not the iterative queries from root to authoritative.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An authoritative answer comes directly from the server that holds the original DNS records for the domain. A non-authoritative answer comes from a resolver's cache (or a server that is not authoritative). The answer may still be correct, but it may be stale. To get an authoritative answer, query the domain's nameservers directly. In nslookup, if you see 'Non-authoritative answer,' the server is not the authoritative source for that domain.
Use the +trace option: `dig +trace example.com`. This makes dig start from the root servers and follow the delegation chain to the authoritative server. It shows each step, including which servers were queried and the response times. This is invaluable for finding where resolution fails. For example, if the root servers respond but the TLD server times out, the issue is with the TLD or network connectivity.
SERVFAIL (Server Failure) indicates that the DNS server encountered a problem processing the query. It could be due to a misconfiguration, a timeout contacting upstream servers, or a DNSSEC validation failure. Unlike NXDOMAIN, which means the domain does not exist, SERVFAIL means the server could not give a definitive answer. Troubleshoot by checking the server's logs, network connectivity, and DNSSEC settings.
Yes. Simply type `nslookup <IP_address>`. This performs a reverse lookup by querying the PTR record for that IP. Alternatively, in interactive mode, you can set the query type to PTR. For dig, use `dig -x <IP_address>`. Reverse lookups are used for logging, email authentication, and security checks.
These are DNS header flags. qr (query response) indicates the message is a response. rd (recursion desired) was set in the query. ra (recursion available) indicates the server supports recursive queries. If you see 'aa' (authoritative answer), the server is authoritative for the domain. Understanding these flags helps interpret the server's role. For example, if ra is missing, the server does not allow recursion.
Use `dig +dnssec example.com`. Look for the 'ad' (authentic data) flag in the header. If present, the response has been validated. Also, the RRSIG records will be present in the answer. If the ad flag is missing, DNSSEC validation failed or is not configured. For deeper checks, use `dig +dnssec +trace` to see each step's signature.
In nslookup, use `-type=MX` (e.g., `nslookup -type=MX example.com`). In dig, specify the type after the name (e.g., `dig example.com MX`). Both support common types: A, AAAA, CNAME, MX, NS, SOA, TXT, PTR. dig also supports more obscure types like SRV, CAA, and SSHFP. The exam focuses on the common types listed in the objectives.
You've just covered DNS Troubleshooting: nslookup and dig — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?