nslookup in Windows: DNS troubleshooting from basic queries to AD diagnostics

Every DNS problem in a Windows environment starts the same way: something that should resolve doesn’t, and you need to know why. nslookup is the tool that answers that question — quickly, without installing anything, and directly from the machine experiencing the problem. Unlike higher-level tools that abstract DNS behind layers of caching and fallback logic, nslookup talks to the DNS server directly and shows you exactly what it returns. That directness is what makes it indispensable for AD troubleshooting, where the difference between what should resolve and what actually resolves can be the root cause of login failures, replication errors, and Group Policy problems.

This article goes beyond basic syntax. It covers practical scenarios from real AD environments — querying SRV records to diagnose domain join failures, detecting split-brain DNS, using nslookup’s interactive mode efficiently, and using the CHAOS DNS class to fingerprint which server is actually answering your queries.

Quick answer

The minimal working form — resolve a hostname using the system’s configured DNS server:

nslookup DC01.corp.local

To query a specific DNS server instead of the system default:

nslookup DC01.corp.local 192.168.1.10

What nslookup does

nslookup sends DNS queries directly to a DNS server and displays the raw response. It bypasses the Windows DNS Client service cache, which means it shows you what the DNS server actually returns — not what Windows has stored locally. This distinction matters in troubleshooting: ipconfig /displaydns shows the cache, nslookup shows the truth.

It operates in two modes. Non-interactive mode handles a single query and exits — useful in scripts and one-off checks. Interactive mode opens a prompt where you can run multiple queries against the same server, change query types, and adjust settings without re-specifying the server each time.

nslookup is built into every version of Windows and requires no installation or elevation. It uses the DNS server configured on the network adapter — or a server you specify explicitly.

Common flags

FlagWhat it does
nslookup hostnameResolve hostname using system DNS
nslookup hostname serverQuery a specific DNS server
nslookup -type=A hostnameQuery A records (IPv4)
nslookup -type=AAAA hostnameQuery AAAA records (IPv6)
nslookup -type=MX domainQuery mail exchanger records
nslookup -type=SRV recordQuery service locator records
nslookup -type=TXT hostnameQuery TXT records (SPF, verification, CHAOS)
nslookup -type=PTR ipReverse DNS lookup
nslookup -type=NS domainQuery name server records
nslookup -type=SOA domainQuery start of authority record
nslookup -debug hostnameShow full query/response detail
nslookup -timeout=10 hostnameSet query timeout in seconds

Practical examples

1. Verify a host resolves correctly

The problem: A user reports they cannot connect to a server by name. The server is reachable by IP, but not by hostname. You need to determine whether DNS resolution is the issue and which record is being returned.

The solution: Query the A record for the hostname and compare the returned IP against the expected value.

rem Basic A record lookup
nslookup SRV-PROD-01.corp.local

rem Explicit A record query
nslookup -type=A SRV-PROD-01.corp.local

rem Query against a specific DC's DNS to confirm consistency
nslookup -type=A SRV-PROD-01.corp.local DC01.corp.local

Expected output:

Server:  DC01.corp.local
Address:  192.168.1.10

Name:    SRV-PROD-01.corp.local
Address:  192.168.1.55

If the returned IP does not match what you expect, the DNS record is stale or incorrect. If nslookup returns nothing but the server responds to ping by IP, the A record is missing entirely — register it with ipconfig /registerdns on the target machine or create it manually in DNS Manager.

Note: nslookup does not use the Windows DNS Client cache. If a user’s machine resolves incorrectly but nslookup shows the correct record, the problem is a stale cache entry. Run ipconfig /flushdns on the affected machine to clear it.

2. Query Active Directory SRV records

The problem: A workstation cannot join the domain, a user gets “no logon servers available,” or replication fails with error 1908 (could not find domain controller). These failures are almost always DNS — specifically, missing or incorrect SRV records that tell clients where to find domain services.

The solution: Query the SRV records that Active Directory depends on and verify they point to the correct DCs.

rem LDAP service locator — used for domain joins and AD queries
nslookup -type=SRV _ldap._tcp.corp.local

rem Kerberos service locator — used for authentication
nslookup -type=SRV _kerberos._tcp.corp.local

rem Global Catalog — used for forest-wide searches
nslookup -type=SRV _gc._tcp.corp.local

rem PDC Emulator locator — used by clients to find the PDC
nslookup -type=SRV _ldap._tcp.pdc._msdcs.corp.local

rem Kerberos in specific site — useful in multi-site environments
nslookup -type=SRV _kerberos._tcp.Default-First-Site-Name._sites.corp.local

Expected output for _ldap._tcp.corp.local:

_ldap._tcp.corp.local   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = DC01.corp.local
_ldap._tcp.corp.local   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = DC02.corp.local
Warning: If SRV records are missing, AD authentication and domain joins will fail even if all DCs are online. Missing SRV records usually mean the Netlogon service on a DC failed to register them. Run nltest /dsregdns or restart Netlogon (net stop netlogon && net start netlogon) to force re-registration.

3. Reverse DNS lookup and PTR records

The problem: Security logs and mail server logs show IP addresses instead of hostnames, making it difficult to trace which machine generated specific traffic. Or a mail server rejects messages because the sending IP has no PTR record matching the FQDN.

The solution: Query the PTR record for the IP to verify what reverse DNS returns.

rem Reverse lookup for an internal server
nslookup -type=PTR 192.168.1.55

rem Shorthand — nslookup accepts IP directly and infers PTR query
nslookup 192.168.1.55

rem Reverse lookup against a specific DNS server (useful to check internal vs external)
nslookup 192.168.1.55 DC01.corp.local

rem Check reverse DNS for a mail server's public IP
nslookup -type=PTR 203.0.113.45 8.8.8.8

Expected output:

Server:  DC01.corp.local
Address:  192.168.1.10

55.1.168.192.in-addr.arpa  name = SRV-PROD-01.corp.local
Note: For internal networks, PTR records live in a reverse lookup zone in your AD DNS (e.g. 1.168.192.in-addr.arpa). If reverse lookups fail internally, check whether that zone exists in DNS Manager and whether the zone is configured for dynamic updates.

4. Query a specific DNS server without changing system settings

The problem: You need to verify what a particular DC’s DNS returns for a record — without changing the network adapter settings on your machine. This is essential when troubleshooting replication between sites, where each site has its own DNS server and you need to confirm they return consistent records.

The solution: Pass the target DNS server as the second argument to nslookup.

rem Query DC01's DNS for a specific host
nslookup SRV-APP-01.corp.local DC01.corp.local

rem Query DC02's DNS for the same host — compare results
nslookup SRV-APP-01.corp.local DC02.corp.local

rem Query an external resolver to check public DNS propagation
nslookup corp.local 8.8.8.8

rem Check what a forwarder returns for an external name
nslookup google.com DC01.corp.local

If DC01 and DC02 return different IPs for the same hostname, you have a replication or zone transfer issue. If DC01 returns the correct result but DC02 does not, the record has not replicated to DC02 yet — check AD replication health with repadmin /showrepl.

Result: Querying multiple DNS servers in sequence is the fastest way to confirm whether a DNS problem is global (all DCs return wrong data) or isolated to a single server (replication or zone issue).

5. Interactive mode for multi-query sessions

The problem: You are diagnosing a complex DNS issue and need to run a series of different query types against the same DNS server — checking A, SRV, PTR, MX, and TXT records one after another. Repeating the server address in every non-interactive command is slow and error-prone.

The solution: Open nslookup in interactive mode, set the server once, and run all queries from the prompt.

rem Start interactive mode
nslookup

rem Inside the interactive prompt:

rem Set a specific DNS server
server DC01.corp.local

rem Set query type to SRV
set type=SRV
_ldap._tcp.corp.local

rem Switch to MX
set type=MX
corp.local

rem Switch to TXT (SPF check)
set type=TXT
corp.local

rem Enable debug output for detailed response info
set debug
SRV-PROD-01.corp.local

rem Disable debug
set nodebug

rem Exit interactive mode
exit
Note: In interactive mode, set type=ALL returns every available record type for a hostname in one query — useful when you are not sure which records exist. The equivalent in non-interactive mode is nslookup -type=ANY hostname, though some DNS servers disable ANY queries for security reasons.

6. Detecting split-brain DNS

The problem: Your internal users reach a different version of a service than external users — or vice versa. A web application works from inside the office but not over VPN. Remote users get the wrong IP for a resource. This is split-brain DNS: the same hostname resolves to different addresses depending on which DNS server answers the query.

The solution: Query both internal and external DNS for the same hostname and compare results.

rem Internal DNS (your DC)
nslookup portal.corp.local DC01.corp.local

rem External DNS (Google) — checks what the public sees
nslookup portal.corp.com 8.8.8.8

rem Cloudflare as second external reference
nslookup portal.corp.com 1.1.1.1

rem Check which authoritative NS servers the domain uses
nslookup -type=NS corp.com 8.8.8.8

rem Query the authoritative nameserver directly (bypasses caching resolvers)
nslookup -type=A portal.corp.com ns1.registrar.com

If the internal DC returns 192.168.1.100 and 8.8.8.8 returns 203.0.113.45 for the same name, split-brain DNS is confirmed. This is intentional in many environments — internal users should hit the internal server. The problem arises when VPN clients or remote workers get routed to the wrong IP because their DNS falls outside the intended zone.

Warning: Split-brain DNS is easy to set up and easy to forget. Problems surface months later when someone changes the public DNS record but forgets the internal zone still points to the old IP — or vice versa. Document your split-brain zones explicitly.

7. Querying DNS server metadata with the CHAOS class

The problem: You have multiple DNS servers in your environment and need to confirm which specific server is answering a query — especially useful when load balancers, anycast configurations, or forwarding chains are involved. Or you are conducting a DNS security audit and need to identify server software versions.

The solution: Use the CHAOS DNS class to query the server’s own identity records. CHAOS is a DNS class (alongside the standard IN — Internet class) that originated in the MIT CHAOS network protocol. DNS servers that support it respond to CHAOS TXT queries with metadata about themselves.

rem Query the DNS server's version (BIND-based servers)
nslookup -class=chaos -type=txt version.bind 192.168.1.10

rem Query the server's hostname as it identifies itself
nslookup -class=chaos -type=txt hostname.bind 192.168.1.10

rem Query server ID (RFC 4892) — more widely supported than version.bind
nslookup -class=chaos -type=txt id.server 192.168.1.10

rem Try against a public resolver to see how they respond
nslookup -class=chaos -type=txt version.bind 8.8.8.8
nslookup -class=chaos -type=txt version.bind 1.1.1.1

On a BIND server that exposes this information, the response looks like:

Server:  192.168.1.10
Address:  192.168.1.10

version.bind        text = "9.16.44"

Most public resolvers deliberately suppress or falsify these responses. Google returns a non-answer, Cloudflare returns a playful string. But internal BIND or Unbound servers often expose this data by default unless hardened explicitly.

Note: Windows DNS Server (the role built into Windows Server) does not implement the CHAOS class and will return a SERVFAIL or no response for these queries. CHAOS queries are most useful when your environment includes BIND-based DNS servers — common in mixed Windows/Linux environments or when using third-party DNS appliances.
Warning: If your internal BIND servers respond to version.bind queries, consider disabling it. Exposing the exact DNS server version makes targeted exploitation easier. In BIND, suppress it with version "not disclosed"; in the options block.

Hidden gems

nslookup and Resolve-DnsName can return different results on the same machine

nslookup queries the DNS server directly, bypassing the Windows DNS Client service. Resolve-DnsName in PowerShell uses the Windows DNS Client API, which goes through the cache and respects local DNS suffixes and search order. If one returns a result and the other does not, the difference is either a cached entry or a DNS suffix search list mismatch. Use ipconfig /displaydns to inspect the cache and ipconfig /flushdns to clear it.

The trailing dot changes query behavior

Running nslookup server1 may trigger DNS suffix appending — Windows tries server1.corp.local, then server1.local, and so on based on the suffix search list. Running nslookup server1. (with a trailing dot) queries for the exact name server1 as a fully qualified domain name, skipping suffix appending entirely. If you get unexpected results for short names, try the trailing dot to rule out suffix interference.

nslookup -debug reveals the full DNS conversation

The -debug flag (or set debug in interactive mode) shows the complete query and response packets — including TTL values, additional records, and whether the answer is authoritative. This is invaluable when tracking down why a record has an unexpectedly low TTL or why additional A records are being returned alongside a SRV record. The -d2 flag goes even deeper, showing the raw packet exchange.

Non-authoritative answer is normal — until it isn’t

The “Non-authoritative answer” line in nslookup output means the DNS server returned a cached result rather than querying the authoritative server directly. This is normal behavior and does not indicate a problem. It becomes significant during troubleshooting: if you are seeing stale data, it is because a caching resolver is serving an old TTL. Query the authoritative server directly (using nslookup -type=NS to find it first) to confirm what the true current record is.

PowerShell equivalent: Resolve-DnsName

Resolve-DnsName is the PowerShell-native alternative introduced in Windows Server 2012 / Windows 8. It returns structured objects rather than plain text, making it significantly more useful in scripts.

# Basic hostname resolution
Resolve-DnsName -Name DC01.corp.local

# Query SRV records
Resolve-DnsName -Name _ldap._tcp.corp.local -Type SRV

# Query against a specific DNS server
Resolve-DnsName -Name SRV-PROD-01.corp.local -Server DC01.corp.local

# Bypass the local DNS cache (equivalent to nslookup behavior)
Resolve-DnsName -Name SRV-PROD-01.corp.local -NoHostsFile -DnsOnly

# Reverse lookup
Resolve-DnsName -Name 192.168.1.55 -Type PTR
Note: Use Resolve-DnsName in scripts — its output is a proper object you can pipe and filter. Use nslookup for quick interactive checks at the command line — it is available on every Windows machine without requiring PowerShell remoting or module imports, and its output is immediately readable. The two tools are complementary, not interchangeable.

Where this matters

Domain join fails — when a workstation cannot join the domain, nslookup against the _ldap._tcp SRV record immediately confirms whether the machine can find a DC at all. If the SRV record is missing, no amount of network troubleshooting will fix the join.

Replication error 1908 — “could not find domain controller” in dcdiag almost always means DNS. Querying _ldap._tcp.corp.local from the failing DC confirms whether it can resolve its replication partners.

GPO not applying — Group Policy relies on SYSVOL access, which requires the DC to be resolvable. If a client resolves a DC to a stale or wrong IP, GPO processing silently fails. nslookup confirms what IP the client is being sent to.

Mail delivery failures — querying MX records and PTR records with nslookup is the first step when diagnosing bounced outbound mail or rejected inbound connections. A missing or mismatched PTR record is one of the most common causes of mail server blacklisting.

VPN split-DNS problems — when remote workers can access some internal resources but not others, querying from inside and outside the VPN with nslookup quickly reveals whether the DNS resolution path is the cause and which records are affected.

Tips and limitations

nslookup does not use the Windows DNS Client cache. This is its greatest strength for troubleshooting and its biggest source of confusion. When users report a name does not resolve but nslookup shows it correctly, the problem is always in the cache or the hosts file — not DNS itself.

The “server can’t find” response means different things in different contexts. It can mean the record genuinely does not exist (NXDOMAIN), the DNS server is not authoritative for that zone and has no cached answer, or the query timed out. Use -debug to distinguish between these cases.

nslookup is technically deprecated according to some RFCs and vendor recommendations in favor of dig on Linux and Resolve-DnsName on Windows. In practice, it remains available on every Windows system and is unlikely to disappear. For interactive troubleshooting at a Windows command prompt, it remains the fastest tool available.

Timeouts do not always mean the server is down. A query timeout can mean the server is filtering the query type, the firewall is blocking UDP port 53, or the server is overloaded. Try -timeout=20 before concluding the server is unreachable, and test TCP fallback with -vc (virtual circuit) flag in interactive mode.

Official reference

nslookup — Windows Commands | Microsoft Learn

Related guides