nslookup – DNS Query Tool: Records, Troubleshooting & Output Interpretation

1. What Is nslookup?

nslookup (name server lookup) is a cross-platform command-line tool used to query DNS (Domain Name System) servers directly. It lets you send specific DNS queries from your own machine — bypassing the operating system's resolver cache — and inspect the raw response returned by the DNS server. This makes it the standard first-line tool for DNS troubleshooting, record verification, and understanding how DNS resolution actually works.

nslookup is available natively on Windows, macOS, and Linux without any installation required. On Windows it ships as part of the OS; on Linux/macOS it is typically included with the BIND utilities package.

  Where nslookup fits in DNS resolution:

  Your PC
  ┌──────────────────────────────────────────────────────┐
  │  Browser types: www.example.com                      │
  │  OS checks local hosts file → not found              │
  │  OS checks resolver cache  → not found               │
  │  OS asks configured DNS server (e.g., 192.168.1.1)  │
  └──────────────────────┬───────────────────────────────┘
                         │
  nslookup lets you send ──▶  DNS Server (192.168.1.1)
  queries directly here        ↓ cache miss?
  bypassing the OS cache       ↓
                          Recursive query to root/TLD/authoritative servers
                               ↓
                          Returns A record: 93.184.216.34

2. Non-Interactive Mode — Single-Command Queries

In non-interactive mode you pass all arguments on one line and nslookup executes, prints the result, and exits. This is the most common usage for quick checks.

Forward Lookup — Domain to IP (A Record)

C:\> nslookup example.com

Server:  dns.google
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

Reading this output:

Server / Address: The DNS server that answered your query — in this case Google's public DNS (8.8.8.8). The #53 confirms the query went to UDP/TCP port 53.
Non-authoritative answer: The response came from the DNS server's cache, not from the domain's own authoritative name server. The server previously looked it up and stored it — it will be served from cache until the TTL expires.
Name / Address: The resolved A record — 93.184.216.34 is the IPv4 address for example.com.

Reverse Lookup — IP to Domain Name (PTR Record)

C:\> nslookup 8.8.8.8

Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
8.8.8.8.in-addr.arpa   name = dns.google.

A reverse lookup queries the special in-addr.arpa domain. The IP address is reversed and appended with .in-addr.arpa — so 8.8.8.8 becomes 8.8.8.8.in-addr.arpa. The DNS server looks up the PTR record at that address and returns the associated hostname (dns.google.).

Trailing dot on hostnames: The trailing dot in dns.google. is the DNS root — it is always present in fully-qualified domain names (FQDNs) at the protocol level but is normally omitted in everyday use.

Querying a Specific DNS Server

! Syntax: nslookup <domain> <dns-server-ip>

C:\> nslookup example.com 1.1.1.1     ! Query Cloudflare DNS instead of default
C:\> nslookup example.com 8.8.8.8     ! Query Google DNS
C:\> nslookup example.com 192.168.1.1 ! Query your local/corporate DNS server

This is one of nslookup's most useful troubleshooting features: by querying different DNS servers you can isolate whether a resolution failure is on the client's local DNS, a corporate forwarder, or the public internet. The DNS server IP is typically assigned by DHCP or configured statically — see ipconfig / ifconfig to check which DNS server your machine is using.

Querying a Specific Record Type (Non-Interactive)

! Windows syntax:
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=AAAA example.com
nslookup -type=TXT example.com
nslookup -type=SOA example.com

! Linux/macOS syntax (same result, slight variant accepted):
nslookup -query=MX example.com

3. Interactive Mode — Multiple Queries in One Session

Typing nslookup alone (no arguments) enters interactive mode, giving you a > prompt. You can issue multiple queries, change record types, switch DNS servers, and toggle options — all without restarting the tool. Type exit or press Ctrl+C to leave.

C:\> nslookup
Default Server:  192.168.1.1
Address:  192.168.1.1

> set type=MX                    ! Switch query type to MX records
> gmail.com
Server:  192.168.1.1
Address:  192.168.1.1#53

Non-authoritative answer:
gmail.com    mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com    mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com    mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com    mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com    mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.

> server 8.8.8.8                 ! Switch to Google DNS for remaining queries
Default Server:  dns.google
Address:  8.8.8.8

> set type=NS                    ! Now query NS records
> example.com
Non-authoritative answer:
example.com    nameserver = a.iana-servers.net.
example.com    nameserver = b.iana-servers.net.

> set type=any                   ! Query ALL record types
> example.com
[returns all available records for the domain]

> exit

Interactive Mode Options Reference

Command	What It Does	Example
`set type=<type>`	Sets the DNS record type for all subsequent queries	`set type=MX`
`set q=<type>`	Shorthand for `set type`	`set q=AAAA`
`set type=ANY`	Request all record types from the DNS server	`set type=any`
`server <ip>`	Switch to a different DNS server for remaining queries	`server 1.1.1.1`
`set debug`	Enables debug output showing full DNS packet exchange. For deeper packet inspection, use Wireshark.	`set debug`
`set d2`	Very verbose debug — shows all DNS message fields	`set d2`
`set timeout=<n>`	Sets query timeout in seconds (default varies by platform)	`set timeout=10`
`set retry=<n>`	Number of times to retry a timed-out query	`set retry=3`
`set port=<n>`	Use a non-standard DNS port (default 53)	`set port=5353`
`ls -t A <domain>`	Zone transfer request (lists all records if permitted by server)	`ls -t A example.com`
`exit`	Exit interactive mode	`exit`

4. DNS Record Types — What Each One Returns

Record Type	nslookup Command	What It Returns	Use Case
A	`nslookup -type=A example.com`	IPv4 address(es) for the domain	Standard forward lookup; confirm website resolves correctly
AAAA	`nslookup -type=AAAA example.com`	IPv6 address(es) for the domain	Verify IPv6 DNS is configured for dual-stack services. See IPv6 Addressing.
MX	`nslookup -type=MX example.com`	Mail Exchange servers with priority values (lower = higher priority)	Email troubleshooting — verify which servers receive mail for a domain
NS	`nslookup -type=NS example.com`	Authoritative name servers for the domain	Find which DNS servers are authoritative; verify delegation is correct
CNAME	`nslookup -type=CNAME www.example.com`	Canonical name alias — the real name the alias points to	Verify CDN aliases; confirm www is aliased to the correct hostname
PTR	`nslookup 93.184.216.34`	Hostname associated with an IP (reverse DNS)	Email spam checks; network logging; verify PTR matches forward record
SOA	`nslookup -type=SOA example.com`	Start of Authority: primary NS, admin email, serial, refresh, retry, expire, minimum TTL	Verify zone transfer settings; find primary name server; check serial number has incremented after zone changes
TXT	`nslookup -type=TXT example.com`	Text records — commonly SPF, DKIM, DMARC, domain verification tokens	Email security (SPF/DKIM/DMARC verification); site ownership verification for services like Google Search Console
SRV	`nslookup -type=SRV _sip._tcp.example.com`	Service locator — host, port, priority, and weight for a service	VoIP/SIP discovery; Microsoft Teams/Lync; XMPP; Kerberos
ANY	`nslookup -type=ANY example.com`	All records the DNS server is willing to return (varies by server)	Overview lookup; note that many servers now restrict ANY responses

See DNS Record Types for a complete reference on all record types and their full field definitions.

5. Authoritative vs Non-Authoritative Answers

Every nslookup response is either authoritative or non-authoritative. Understanding this distinction is critical for CCNA and real-world DNS troubleshooting.

  DNS hierarchy for example.com:

  Root DNS servers (.)
       ↓
  .com TLD name servers
       ↓
  example.com Authoritative Name Servers
  (a.iana-servers.net / b.iana-servers.net)
  — these servers HOLD the zone data for example.com —
  — they give AUTHORITATIVE answers —
       ↓
  Your Recursive Resolver (e.g., 8.8.8.8 / 192.168.1.1)
  — this server CACHES answers it looks up —
  — it gives NON-AUTHORITATIVE answers (from its cache) —
       ↓
  Your PC running nslookup

Answer Type	What It Means	When You See It	Trustworthiness
Authoritative answer	The response came directly from the DNS server that hosts the zone for this domain — it is the definitive source of truth for that record	When you query the domain's own NS servers directly (e.g., `nslookup example.com a.iana-servers.net`)	Highest — the data is live from the zone file
Non-authoritative answer	The response came from a recursive resolver's cache — it previously looked up the record and is serving the cached copy	When you query a public resolver (8.8.8.8, 1.1.1.1) or your local DNS server — the most common case	Valid until TTL expires — could be slightly stale if recently changed

Practical use: If you just updated a DNS record and nslookup shows the old value from a non-authoritative answer, the change may not have propagated yet — or may have propagated but your resolver's cache still holds the old TTL. Query the authoritative NS directly to confirm the new record is live: first find the NS with nslookup -type=NS example.com, then query it directly with nslookup example.com a.iana-servers.net.

6. TTL — Time to Live in DNS

Every DNS record has a TTL (Time to Live) — the number of seconds that resolvers are allowed to cache the record before they must look it up again. nslookup's standard output does not show TTL by default, but debug mode does.

! Enable debug to see TTL in nslookup output
> set debug
> example.com

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NOERROR
        flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
    QUESTIONS:
        example.com, type = A, class = IN
    ANSWERS:
    ->  example.com
        internet address = 93.184.216.34
        ttl = 86400  (1 day)        ← TTL shown in debug mode
------------

TTL Value	Meaning	When to Use
300 seconds (5 min)	Short cache time — changes propagate quickly	Before planned DNS changes; failover records; testing
3600 seconds (1 hour)	Common default for most records	Regular records that rarely change
86400 seconds (24 hours)	Long cache — very slow propagation	Stable records like NS delegations; reduces resolver query load

DNS change propagation: When you change a DNS record, resolvers that have cached the old record will keep serving it until their cached TTL expires. If you want changes to take effect quickly, reduce the TTL to 300 seconds before making the change. After propagation is confirmed, restore a longer TTL. See DNS Record Types for a full reference. Use dig's output to see TTL values without needing debug mode.

7. Reading nslookup Output — Complete Field Reference

  nslookup example.com 8.8.8.8
  ─────────────────────────────────────────────────────────────────
  Server:  dns.google         ← DNS server that answered the query
  Address: 8.8.8.8#53         ← IP and port of responding DNS server
                                 (port 53 is the standard DNS port)
  Non-authoritative answer:   ← Response from resolver cache (not authoritative NS)
  Name:    example.com        ← The hostname you queried
  Address: 93.184.216.34      ← IPv4 address returned (A record)
  ─────────────────────────────────────────────────────────────────

  nslookup -type=MX gmail.com
  ─────────────────────────────────────────────────────────────────
  Non-authoritative answer:
  gmail.com    mail exchanger = 5 gmail-smtp-in.l.google.com.
               ↑ priority        ↑ mail server hostname
  gmail.com    mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
  ! Lower priority value = higher preference
  ! Mail is attempted in preference order (5 first, then 10, 20, 30, 40)
  ─────────────────────────────────────────────────────────────────

  nslookup -type=SOA example.com
  ─────────────────────────────────────────────────────────────────
  example.com
        origin = ns.icann.org          ← Primary name server
        mail addr = noc.dns.icann.org  ← Admin email (@ replaced with .)
        serial = 2023112754            ← Zone serial number (increment on every change)
        refresh = 7200                 ← Secondary NS polls primary every 7200 seconds
        retry = 3600                   ← On refresh failure, retry every 3600 seconds
        expire = 1209600               ← Secondary stops serving if no refresh for 14 days
        minimum = 3600                 ← Default negative cache TTL (NXDOMAIN cacheable for)
  ─────────────────────────────────────────────────────────────────

  nslookup -type=TXT example.com
  ─────────────────────────────────────────────────────────────────
  example.com    text = "v=spf1 -all"
                 ↑ SPF record: "-all" means no servers are authorised to send email for
                   this domain — any email claiming to be from @example.com should be rejected
  ─────────────────────────────────────────────────────────────────

8. Common nslookup Error Messages Explained

Error Message	Meaning	Likely Cause	Troubleshooting Steps
`Server can't find example.com: NXDOMAIN`	Non-Existent Domain — the queried name does not exist in DNS	Typo in hostname; domain has expired or was deleted; DNS record has not been created yet	Check spelling; verify record exists with authoritative NS; check domain registration status
`*** Request to <server> timed-out`	The DNS server did not respond within the timeout period	DNS server is down; firewall blocking UDP/TCP port 53; network connectivity issue to DNS server	`ping <dns-server-ip>` to test reachability; verify port 53 not blocked by firewall or ACL; try alternate DNS server (8.8.8.8)
`Server can't find example.com: SERVFAIL`	Server Failure — the DNS server encountered an error resolving the query	Authoritative NS is unreachable; misconfigured zone; DNSSEC validation failure	Try a different resolver; check if the domain's authoritative NS are responding; contact domain admin
`Server can't find example.com: REFUSED`	The DNS server explicitly refused to answer the query	Server configured to deny queries from your IP (common on authoritative servers that only serve their own zones)	Use a recursive resolver instead of querying authoritative NS directly for general lookups
`Non-authoritative answer:` (returns unexpected IP)	Record resolved but returns wrong IP	DNS record not updated after IP change; old record cached; possible DNS poisoning; split-horizon DNS serving wrong answer	Query authoritative NS directly to see live record; check if TTL has expired; verify record value in DNS management console
`Can't find server name for address <ip>: NXDOMAIN`	Reverse lookup failure — no PTR record exists for this IP	PTR record not configured for the IP address	PTR records are configured by the IP address owner (usually the ISP or hosting provider) — request PTR record creation

9. Step-by-Step DNS Troubleshooting with nslookup

The following is the systematic approach for diagnosing DNS failures using nslookup.

  Scenario: User cannot reach www.example.com — "Website not found" error.

  Step 1 — Basic resolution test (default DNS server):
  ───────────────────────────────────────────────────
  C:\> nslookup www.example.com

  If fails (NXDOMAIN or timeout) → DNS issue confirmed.
  If succeeds → DNS is working; problem is elsewhere (routing, firewall, app).

  Step 2 — Test with alternate public DNS (bypass local resolver):
  ───────────────────────────────────────────────────────────────
  C:\> nslookup www.example.com 8.8.8.8

  If works with 8.8.8.8 but not local DNS → local DNS server problem.
  If fails with both → upstream DNS problem or domain does not exist.

  Step 3 — Check local DNS configuration:
  ───────────────────────────────────────
  C:\> ipconfig /all          (Windows) — check DNS server IP listed
  $ cat /etc/resolv.conf      (Linux)   — check nameserver entries

  Ensure client is pointing to the correct DNS server.
  See: dns-client-router-config.html

  Step 4 — Find the authoritative NS servers:
  ───────────────────────────────────────────
  C:\> nslookup -type=NS example.com 8.8.8.8

  Output shows: a.iana-servers.net., b.iana-servers.net.

  Step 5 — Query the authoritative NS directly:
  ──────────────────────────────────────────────
  C:\> nslookup www.example.com a.iana-servers.net

  If authoritative NS returns the record → DNS is correct, may be a propagation
  delay or caching issue.
  If authoritative NS also fails → the record is genuinely missing or misconfigured.

  Step 6 — Check for specific record types:
  ──────────────────────────────────────────
  C:\> nslookup -type=A www.example.com       (IPv4 address)
  C:\> nslookup -type=AAAA www.example.com    (IPv6 address)
  C:\> nslookup -type=CNAME www.example.com   (is it an alias?)

  Step 7 — Test connectivity to DNS server port 53:
  ──────────────────────────────────────────────────
  C:\> ping 8.8.8.8        (basic reachability)
  C:\> nslookup -type=A google.com 8.8.8.8  (can queries actually reach it?)

  Step 8 — Flush DNS cache (Windows) and retest:
  ────────────────────────────────────────────────
  C:\> ipconfig /flushdns
  Successfully flushed the DNS Resolver Cache.

  C:\> nslookup www.example.com    (fresh query — no cached answer)

Use ping to test basic reachability and traceroute to identify where connectivity breaks down. If firewall rules or ACLs may be blocking port 53, check those configurations on the path to the DNS server. Also see Wireshark for capturing DNS traffic at the packet level.

10. Email Troubleshooting with nslookup (MX, PTR, SPF/TXT)

nslookup is heavily used for email delivery troubleshooting. Email servers use DNS in several ways and problems with these records cause mail delivery failures.

  ! Step 1: Find which servers receive mail for a domain
  C:\> nslookup -type=MX company.com

  company.com    mail exchanger = 10 mail1.company.com.
  company.com    mail exchanger = 20 mail2.company.com.

  Interpretation:
  - mail1.company.com is the primary (priority 10)
  - mail2.company.com is the backup (priority 20)
  - Sending servers try priority 10 first; if unreachable, try 20

  ! Step 2: Resolve the MX hostname to an IP
  C:\> nslookup mail1.company.com
  Address: 203.0.113.10

  ! Step 3: Verify reverse DNS (PTR) for the sending mail server
  C:\> nslookup 203.0.113.10
  Name: mail1.company.com.   ← PTR matches forward A record — good

  If PTR is missing or mismatched, many mail servers will reject or junk-folder
  the email ("PTR record mismatch" or "no reverse DNS")

  ! Step 4: Check SPF record (TXT) — which servers are allowed to send email
  C:\> nslookup -type=TXT company.com

  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all"
  Interpretation:
  - ip4:203.0.113.0/24: servers in this range are authorised
  - include:_spf.google.com: Google's servers are also authorised (GSuite/Workspace)
  - ~all: "softfail" — other senders should be treated with suspicion but not rejected

  ! Step 5: Check DMARC policy (TXT at _dmarc subdomain)
  C:\> nslookup -type=TXT _dmarc.company.com

  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@company.com"
  - p=quarantine: failing emails go to spam
  - p=reject: failing emails are rejected outright
  - p=none: monitoring only

11. nslookup on Cisco IOS

Cisco routers and switches also support DNS lookups. The nslookup command (or ip host lookup) on IOS lets you test DNS resolution directly from a router — useful for verifying that the router's DNS configuration is correct and the DNS server is reachable.

! Cisco IOS DNS configuration (prerequisite for nslookup to work):
Router(config)# ip domain-lookup              ! Enable DNS lookup (on by default)
Router(config)# ip name-server 8.8.8.8        ! Primary DNS server
Router(config)# ip name-server 8.8.4.4        ! Secondary DNS server
Router(config)# ip domain-name company.local  ! Default domain suffix

! Test DNS from Cisco IOS (privileged exec mode):
Router# nslookup www.example.com
Translating "www.example.com"...domain server (8.8.8.8) [OK]
www.example.com has address 93.184.216.34

! Alternatively — ping by hostname (also validates DNS):
Router# ping www.google.com
Translating "www.google.com"...domain server (8.8.8.8) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 142.250.x.x, timeout is 2 seconds:
!!!!!
Success rate is 100 percent

! Verify DNS configuration on router:
Router# show hosts                    ! Cached hostname-to-IP mappings
Router# show running-config | include name-server   ! DNS server config

See show running-config for verifying DNS and other router settings. SSH must be configured to access the router remotely for DNS testing. The DNS server IPs configured with ip name-server are typically provided by DHCP or set statically by the administrator.

12. nslookup vs dig vs host — Full Comparison

Feature	nslookup	dig	host
Platform	Windows, Linux, macOS — built-in everywhere	Linux/macOS standard; Windows via BIND install	Linux/macOS; rarely on Windows
Output verbosity	Moderate — shows server, answer, and flags	Very detailed — full DNS message sections (QUESTION, ANSWER, AUTHORITY, ADDITIONAL, timing)	Minimal — one line per answer
Scripting / automation	Limited — interactive mode not scriptable; output format varies by platform	Excellent — `+short` flag gives clean single-value output ideal for scripts and pipes	Simple — easy to parse in scripts but less flexible
TTL visibility	Only with `set debug`	Always shown in ANSWER section	Shown by default
DNSSEC support	Limited — cannot validate DNSSEC chains	Full — `+dnssec`, `+sigchase`, view DS, DNSKEY, RRSIG records	Basic — shows signed responses but no validation
Reverse lookup syntax	`nslookup 8.8.8.8`	`dig -x 8.8.8.8`	`host 8.8.8.8`
Specify DNS server	`nslookup example.com 8.8.8.8`	`dig @8.8.8.8 example.com`	`host example.com 8.8.8.8`
Query specific record type	`nslookup -type=MX example.com`	`dig MX example.com`	`host -t MX example.com`
TCP mode (for large responses)	Automatic on truncation	`+tcp` flag forces TCP	Automatic
Best for	Quick checks on any platform; Windows environments; interactive multi-record sessions	Detailed diagnostics; scripting; DNSSEC; email record verification; professional DNS troubleshooting. See dig Command.	Quick, clean single-line lookups; simple shell scripts

13. Platform Notes and Limitations

Platform	Notes
Windows	nslookup is built in and fully supported. Default DNS server comes from NIC configuration (set by DHCP or manually). `ipconfig /flushdns` clears the OS resolver cache. The `-type=` syntax is used (with a hyphen). nslookup queries bypass the Windows hosts file and resolver cache — it sends directly to the configured DNS server.
Linux	nslookup is available via the `bind-utils` (RHEL/CentOS) or `dnsutils` (Debian/Ubuntu) package. Default DNS server comes from `/etc/resolv.conf`. The `-query=` syntax may also work. dig is the preferred tool on Linux for detailed diagnostics.
macOS	nslookup is included. Default DNS from System Preferences → Network. Uses `-type=` syntax (same as Windows). Note that macOS uses mDNSResponder which may give different results than direct nslookup for `.local` domains (mDNS/Bonjour). nslookup bypasses mDNSResponder and queries the configured DNS server directly.
Cisco IOS/IOS-XE	The `nslookup` command is available in privileged exec mode and queries the DNS servers configured with `ip name-server`. If DNS is not configured (`no ip domain-lookup`), the command will fail. Verify configuration with `show running-config`.

Key Limitations of nslookup

Cannot perform DNSSEC chain validation — use dig +dnssec for that
Output format is not consistent across platforms (Windows vs Linux can differ slightly)
Limited scripting support — dig +short is far easier to parse in scripts
Does not show TTL by default — requires debug mode
The set type=ANY query is increasingly unreliable as many DNS servers now restrict ANY responses (RFC 8482) to reduce abuse

14. Key Points & Exam Tips

nslookup queries DNS servers directly, bypassing the OS resolver cache — this is why it shows different results from the browser in some cases.
Syntax: nslookup <domain> (forward lookup), nslookup <IP> (reverse lookup / PTR), nslookup <domain> <dns-server> (specify server).
Record types: A = IPv4, AAAA = IPv6, MX = mail server, NS = name servers, CNAME = alias, PTR = reverse DNS, SOA = zone authority info, TXT = SPF/DKIM/DMARC/verification. See DNS Record Types.
Authoritative answer = directly from the zone's own name server (live data). Non-authoritative answer = from a resolver's cache (may be slightly stale).
MX record priority: lower number = higher preference. Mail tries lowest priority value first.
Reverse lookup uses in-addr.arpa — IP is reversed and appended: 8.8.8.8 → 8.8.8.8.in-addr.arpa.
Interactive mode: nslookup alone → > prompt. Use set type=MX, server 8.8.8.8, set debug. Exit with exit.
SOA record fields: primary NS, admin email, serial (increment on every change), refresh, retry, expire, minimum TTL.
NXDOMAIN = domain/record does not exist. SERVFAIL = server error resolving query. REFUSED = server won't answer your query.
On Cisco IOS: ip name-server <IP> configures DNS; ip domain-lookup enables it; nslookup <hostname> tests from router. Check with show running-config.
Prefer dig over nslookup for scripts, DNSSEC diagnostics, and detailed output — nslookup is the go-to for quick cross-platform checks.
DNS uses port 53 (UDP for queries under 512 bytes, TCP for larger responses). A firewall or ACL blocking port 53 will prevent resolution.

15. nslookup – DNS Query Tool Quiz

1. A network engineer runs `nslookup example.com 8.8.8.8` and receives the correct IP address. She then runs `nslookup example.com 192.168.1.1` (the local corporate DNS) and gets NXDOMAIN. What does this tell her and what is the likely fix?

A. The domain has expired — contact the domain registrar B. The client's network adapter is misconfigured C. Port 53 is blocked on the firewall for external queries D. The local DNS server (192.168.1.1) is not configured to forward external queries to a public resolver — it is either not forwarding at all or not authoritative for external names. Fix: configure the corporate DNS with a forwarder to 8.8.8.8 or another upstream resolver

Correct answer is D. The fact that 8.8.8.8 resolves the domain correctly but the local DNS (192.168.1.1) returns NXDOMAIN clearly isolates the problem to the local DNS server — the domain itself exists and is working. The most common cause in a corporate environment: the internal DNS server is authoritative only for internal zones (e.g., company.local) and is not configured with a forwarder for external domain resolution. Fix: on the DNS server, configure a forwarder pointing to a public resolver (8.8.8.8 or 1.1.1.1) so that queries for external domains are forwarded upstream. On Cisco IOS as DNS server: ip dns server + ip name-server 8.8.8.8. This is exactly the diagnostic value of testing with both a local and public DNS server in the same troubleshooting session. See DNS Client & Router Configuration.

2. An email administrator reports that emails sent from the company's mail server (203.0.113.25) are being rejected by external recipients with the message "No PTR record found." What nslookup command diagnoses this, and what is the fix?

A. nslookup -type=MX company.com — add an MX record pointing to the mail server B. nslookup 203.0.113.25 — this performs a reverse lookup (PTR query) for the sending IP. If it returns NXDOMAIN or no result, no PTR record exists. Fix: request the ISP or hosting provider (who owns the IP block) to create a PTR record mapping 203.0.113.25 to the mail server's FQDN (e.g., mail.company.com) C. nslookup -type=TXT company.com — check and fix the SPF record D. nslookup -type=NS company.com — check that the correct name servers are delegated

Correct answer is B. PTR (Pointer) records are reverse DNS records that map an IP address to a hostname. They live in the in-addr.arpa zone. Running nslookup 203.0.113.25 performs a reverse lookup — if it returns NXDOMAIN or "can't find server name," no PTR record exists for that IP. Many receiving mail servers check PTR records as an anti-spam measure: if the sending IP has no PTR record (or if the PTR does not match the A record of the sending hostname), the email is rejected or junk-foldered. Critical: PTR records are created by whoever owns the IP address block — typically the ISP or hosting provider, not the domain owner. The company must contact their ISP and request: "Please add a PTR record for 203.0.113.25 pointing to mail.company.com." Also verify the forward A record for mail.company.com resolves to 203.0.113.25 so forward and reverse match. See DNS Record Types.

3. A network team just updated an A record for www.company.com from 192.0.2.10 to 192.0.2.50. Users on different parts of the internet report inconsistent behaviour — some see the new IP, others still get the old one. nslookup of the authoritative NS returns 192.0.2.50 correctly. What explains the inconsistency?

A. The DNS change was only applied to one of the two authoritative name servers B. The authoritative NS is returning random answers (round-robin DNS) C. Different recursive resolvers around the internet have cached the old A record (192.0.2.10) and will continue serving it until their cached TTL expires — resolvers that had not cached the record will get the new IP immediately; others wait for their cached copy to expire D. The old server (192.0.2.10) is still responding and intercepting some requests

Correct answer is C. This is DNS propagation delay — one of the most common DNS change issues. The authoritative NS returning the new IP confirms the change was correctly applied at the source. However, recursive resolvers worldwide cache DNS records for the duration of their TTL. Any resolver that had cached the old A record (192.0.2.10) before the change will keep serving that cached answer until the TTL countdown reaches zero. Best practice: reduce TTL to 300 seconds (5 minutes) at least 48 hours before a planned IP change, make the change, then restore the normal TTL after verifying propagation. Use dig to check TTL values without enabling debug mode.

4. In interactive nslookup mode, an engineer runs `set type=SOA` then queries `company.com`. The serial number returned is 2023010501. After making a DNS zone change, she runs the same query again and gets serial 2023010501. What does this indicate?

A. The zone serial number was not incremented after the change — secondary DNS servers will not know to transfer the updated zone and may serve stale records. The serial must be increased before or when saving zone changes B. The SOA record is cached — wait for TTL to expire and the new serial will appear C. The SOA serial is only updated once per day regardless of changes D. The change has propagated successfully — the serial stays the same when changes are minor

Correct answer is A. The SOA (Start of Authority) serial number is the mechanism that secondary DNS servers use to determine whether they need to transfer an updated zone copy from the primary. Secondary servers periodically check (at the SOA refresh interval) whether the primary's serial number is higher than their own — if it is, they initiate a zone transfer (AXFR/IXFR) to get the new records. If the serial number has not been incremented, secondary servers see no change and do not transfer the zone — they continue serving their old, stale copy. A common convention for serial numbers is the date format YYYYMMDDNN where NN is a daily revision counter (e.g., 2024031501 = March 15, 2024, revision 01). Every time a zone is modified and saved, the serial must be incremented. nslookup with set type=SOA is the standard way to verify the primary NS has the current serial after a change. See DNS Record Types for SOA field definitions.

5. An engineer discovers via nslookup that `www.company.com` resolves to different IPs depending on which DNS server is queried — the internal corporate DNS returns 10.0.0.5 (internal server), while 8.8.8.8 returns 203.0.113.15 (public server). The same hostname, two different answers. What architecture explains this?

A. DNS round-robin — the DNS server randomly returns one of several IPs B. A DNS poisoning attack — the internal DNS has been compromised C. Split-horizon (split-brain) DNS — the internal DNS is intentionally configured to return a private IP for internal users while the public DNS returns the internet-facing IP; this allows the same hostname to route to the correct server depending on where the query originates D. The public DNS is misconfigured and needs updating

Correct answer is C. Split-horizon DNS (also called split-brain or split-view DNS) is an intentional design where the same hostname returns different answers based on who is asking. The internal DNS serves internal clients and returns the internal IP (10.0.0.5) so traffic stays on the LAN and doesn't hairpin out to the internet and back in. The public DNS serves external users and returns the internet-facing IP (203.0.113.15). This is extremely common in enterprises: the internal web server and public web server may be the same physical machine with different interfaces, or the internal IP may be a load balancer on the LAN. nslookup is the perfect tool to diagnose this — by querying both the internal DNS and a public resolver, you immediately see whether split DNS is in place and whether both views are correctly configured. See DNS Client and Router Configuration for how to configure DNS views on Cisco devices.

6. What does a `SERVFAIL` response from nslookup indicate, and how does it differ from `NXDOMAIN`?

A. SERVFAIL means the DNS server refused the query; NXDOMAIN means the server is unavailable B. SERVFAIL means the resolver encountered an error while trying to resolve the name (e.g., authoritative NS unreachable, DNSSEC validation failure, or misconfigured zone); NXDOMAIN means the query succeeded but the name definitively does not exist in DNS C. SERVFAIL means no PTR record exists; NXDOMAIN means no A record exists D. Both indicate the same condition — the domain does not exist

Correct answer is B. These are two distinct DNS response codes with very different meanings. NXDOMAIN (Non-Existent Domain, RCODE=3) is a definitive answer: the authoritative name server confirmed that this name does not exist in DNS. SERVFAIL (Server Failure, RCODE=2) means the resolver could not complete the resolution process — something went wrong mid-resolution. Common causes: (1) The authoritative name servers for the domain are unreachable. (2) DNSSEC validation failure. (3) Zone misconfiguration. SERVFAIL often indicates a temporary or configuration problem rather than the name genuinely not existing. Use ping and traceroute to check reachability to the DNS server if SERVFAIL persists.

7. A security engineer is investigating a potential DNS-based attack. She notices that `nslookup example.com` returns a different IP than expected. She queries the authoritative NS directly with `nslookup example.com a.iana-servers.net` and gets the correct IP. What does this indicate?

A. The authoritative NS is compromised B. The domain's A record was recently changed and is still propagating C. A CDN is providing geo-based DNS responses D. The recursive resolver (local DNS) may have a poisoned cache — a corrupt or malicious entry was injected into the resolver's cache, making it return a false IP. This is DNS cache poisoning. The local resolver should be flushed and investigated; an attacker may have redirected traffic to a malicious server

Correct answer is D. This scenario describes the classic diagnostic signature of DNS cache poisoning. The key observation: the authoritative NS returns the correct IP — meaning the actual DNS record is correct. But the local recursive resolver returns a different (incorrect) IP — meaning the resolver's cache contains a false record. This is the hallmark of DNS cache poisoning: an attacker has injected a forged DNS response into the resolver's cache, causing it to return a malicious IP that points to an attacker-controlled server (for phishing, credential theft, or malware delivery). Recovery steps: flush the resolver's cache immediately; investigate how the poisoning occurred; ensure the resolver is running DNSSEC validation; consider deploying DNS-over-HTTPS or DNS-over-TLS. Use Wireshark to capture DNS traffic and inspect the forged responses. The systematic use of nslookup to compare resolver vs authoritative NS responses is precisely the technique used to detect this attack.

8. When configuring a new Cisco router for DNS, an engineer enters `ip name-server 8.8.8.8` but the command `nslookup google.com` fails with "Translating... % Unrecognized host or address." What is the likely missing configuration?

A. The ip domain-lookup command is missing — DNS lookups are disabled on this router. Adding ip domain-lookup in global config enables the router to resolve hostnames B. The router needs ip name-server 8.8.4.4 as a secondary DNS before the primary works C. Port 53 must be opened with an ACL on the outside interface D. The router requires a hostname command before DNS will function

Correct answer is A. On Cisco IOS, DNS lookup is enabled by default but is commonly disabled by engineers who type no ip domain-lookup to prevent the router from attempting DNS resolution when a mistyped command is entered in exec mode (the router would otherwise hang for ~30 seconds trying to resolve the mistyped word as a hostname). If someone previously ran no ip domain-lookup, the router will not perform DNS resolution regardless of whether a name server is configured. Fix: Router(config)# ip domain-lookup. With both ip domain-lookup (enabled) and ip name-server 8.8.8.8 configured, the router can resolve hostnames. Verify with nslookup google.com from privileged exec mode. Check the full configuration with show running-config.

9. An nslookup query for `mail.company.com` returns a `CNAME` record pointing to `hosted-mail.provider.com`, which then resolves to an IP. An email client is failing to connect to the mail server. What should the engineer check next?

A. The CNAME record is invalid — mail servers cannot use CNAME records; replace with a direct A record B. The TTL of the CNAME record is too short C. Verify that hosted-mail.provider.com resolves to the correct IP, that the mail service is running on that IP, and that the required ports (TCP 25/587/993/995) are reachable — DNS resolution succeeding does not mean the service is up or accessible D. The MX record must point to the CNAME, not to an A record

Correct answer is C. This tests the critical understanding that DNS resolution and service connectivity are different things. nslookup confirming that mail.company.com → CNAME → hosted-mail.provider.com → IP means DNS is working correctly. But "cannot connect" means the problem is at a different layer. Next steps: (1) Confirm hosted-mail.provider.com resolves to the expected IP (it might have changed). (2) Test TCP connectivity to the mail ports: use telnet hosted-mail.provider.com 25 (SMTP), port 587 (SMTP submission), port 993 (IMAPS), port 995 (POP3S). (3) Check for firewall rules or ACLs blocking outbound mail ports. (4) Verify TLS/SSL certificates are valid. See Common Port Numbers for mail port reference. Note on CNAME and MX: RFC 2181 states that MX records should not point to CNAME aliases — MX must point directly to A records. However, CNAME for mail.company.com (not the MX target itself) is fine.

10. Why might an engineer prefer `dig` over `nslookup` when writing a shell script that extracts just the IP address of a hostname for use in an automated monitoring tool?

A. dig is faster than nslookup for single queries B. dig's +short flag outputs only the answer value (e.g., just the IP address) with no headers or metadata — this is trivially parseable in scripts. nslookup's output includes "Server:", "Address:", "Name:", "Non-authoritative answer:" lines that vary by platform and must be parsed with complex text processing to extract just the IP C. nslookup cannot resolve hostnames in shell scripts D. dig supports TCP while nslookup only uses UDP

Correct answer is B. This is the primary practical reason network engineers use dig for scripting. Compare the outputs: nslookup example.com outputs multiple lines including "Server:", "Address:", "Non-authoritative answer:", "Name:", "Address:" — extracting just the IP requires platform-dependent parsing logic (the format differs between Windows and Linux nslookup, and between nslookup versions). dig example.com +short outputs exactly: 93.184.216.34 — nothing else. In a shell script: IP=$(dig example.com +short) immediately gives a clean, usable variable. Other dig scripting advantages: dig +noall +answer gives just the answer section; exit codes are reliable (0 = success, non-zero = failure); output format is consistent across all Unix/Linux platforms. nslookup is excellent for interactive DNS investigation but dig is the correct choice for any scripted or automated DNS lookup.

← Back to Home

nslookup – DNS Query Tool: Records, Troubleshooting & Output Interpretation

1. What Is nslookup?

2. Non-Interactive Mode — Single-Command Queries

Forward Lookup — Domain to IP (A Record)

Reverse Lookup — IP to Domain Name (PTR Record)

Querying a Specific DNS Server

Querying a Specific Record Type (Non-Interactive)

3. Interactive Mode — Multiple Queries in One Session

Interactive Mode Options Reference

4. DNS Record Types — What Each One Returns

5. Authoritative vs Non-Authoritative Answers

6. TTL — Time to Live in DNS

7. Reading nslookup Output — Complete Field Reference

8. Common nslookup Error Messages Explained

9. Step-by-Step DNS Troubleshooting with nslookup

10. Email Troubleshooting with nslookup (MX, PTR, SPF/TXT)

11. nslookup on Cisco IOS

12. nslookup vs dig vs host — Full Comparison

13. Platform Notes and Limitations

Key Limitations of nslookup

14. Key Points & Exam Tips

15. nslookup – DNS Query Tool Quiz

1. A network engineer runs nslookup example.com 8.8.8.8 and receives the correct IP address. She then runs nslookup example.com 192.168.1.1 (the local corporate DNS) and gets NXDOMAIN. What does this tell her and what is the likely fix?

2. An email administrator reports that emails sent from the company's mail server (203.0.113.25) are being rejected by external recipients with the message "No PTR record found." What nslookup command diagnoses this, and what is the fix?

4. In interactive nslookup mode, an engineer runs set type=SOA then queries company.com. The serial number returned is 2023010501. After making a DNS zone change, she runs the same query again and gets serial 2023010501. What does this indicate?

6. What does a SERVFAIL response from nslookup indicate, and how does it differ from NXDOMAIN?

7. A security engineer is investigating a potential DNS-based attack. She notices that nslookup example.com returns a different IP than expected. She queries the authoritative NS directly with nslookup example.com a.iana-servers.net and gets the correct IP. What does this indicate?

8. When configuring a new Cisco router for DNS, an engineer enters ip name-server 8.8.8.8 but the command nslookup google.com fails with "Translating... % Unrecognized host or address." What is the likely missing configuration?

9. An nslookup query for mail.company.com returns a CNAME record pointing to hosted-mail.provider.com, which then resolves to an IP. An email client is failing to connect to the mail server. What should the engineer check next?

10. Why might an engineer prefer dig over nslookup when writing a shell script that extracts just the IP address of a hostname for use in an automated monitoring tool?

1. A network engineer runs `nslookup example.com 8.8.8.8` and receives the correct IP address. She then runs `nslookup example.com 192.168.1.1` (the local corporate DNS) and gets NXDOMAIN. What does this tell her and what is the likely fix?

4. In interactive nslookup mode, an engineer runs `set type=SOA` then queries `company.com`. The serial number returned is 2023010501. After making a DNS zone change, she runs the same query again and gets serial 2023010501. What does this indicate?

6. What does a `SERVFAIL` response from nslookup indicate, and how does it differ from `NXDOMAIN`?

7. A security engineer is investigating a potential DNS-based attack. She notices that `nslookup example.com` returns a different IP than expected. She queries the authoritative NS directly with `nslookup example.com a.iana-servers.net` and gets the correct IP. What does this indicate?

8. When configuring a new Cisco router for DNS, an engineer enters `ip name-server 8.8.8.8` but the command `nslookup google.com` fails with "Translating... % Unrecognized host or address." What is the likely missing configuration?

9. An nslookup query for `mail.company.com` returns a `CNAME` record pointing to `hosted-mail.provider.com`, which then resolves to an IP. An email client is failing to connect to the mail server. What should the engineer check next?

10. Why might an engineer prefer `dig` over `nslookup` when writing a shell script that extracts just the IP address of a hostname for use in an automated monitoring tool?