Resolve-DnsName vs. nslookup in Windows

Oh boy, here we go again. The last time I talked about a networking tool, the infamous iPerf3 article, I kicked up a hornet’s nest online. This one should not be controversial. I hope.

 

The choice of tool you pick to diagnose name resolution, such as DNS, inside Windows can impact the accuracy of your troubleshooting. This article is going to discuss the option every Windows admin knows, nslookup, versus the newer kid on the block, PowerShell’s Resolve-DnsName.

nslookup: The tool we know and love!

nslookup is typically the go-to option for Windows admins when doing name resolution. It works, it works everywhere, and it works (mostly) well. But, because these articles always have a but, it has some quirks that you may not be aware of.

nslookup is a standalone executable which operates independently of the Windows DNS client resolver (DNS-CR). What does this mean?

When an application inside Windows resolves a computer or a domain name, like mapping a drive in File Explorer, it makes one of a handful of API calls. Those API calls will almost always end up at DnsQueryEx(). Nslookup does not use DnsQueryEx(). It does not make any name resolution Windows API calls. This is both good and bad.

The good part? When no Windows-centric troubleshooting is involved, and you just need to resolve an IP address from a DNS server, then nslookup is great. Or, if you suspect that the Windows DNS client resolver (DNS-CR) is acting up, use nslookup! When nslookup works but a Windows process does not, then there is a good chance that there is a Windows, DNS policy, or endpoint protection related issue.

The bad part means that nslookup does not match the name resolution behaviors used by Windows roles, features, services, apps, and most programs running on Windows. This can lead to false results, depending on the type of name resolution troubleshooting you are performing. The biggest gotcha here is that nslookup requires formal dot termination on multi-label names to signify the root domain.

I understand those are words… what do they mean in this order?

A label, in DNS terms, is a portion of a domain name. When there is only one label, it is called a single-label name. This is more commonly known as a short, NetBIOS, or host/computer name. Think of it as a device’s network name without an attached domain. A multi-label name is a DNS name with more than one label. We are imaginative with naming in the network space. This is also known as the Fully Qualified Domain Name (FQDN) or the "website" or domain part of a URL – for example, learn.microsoft.com in the URL: learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname

Each label is separated by a dot, or period. And, when being super technical, a multi-label name or FQDN should be terminated by a dot. While this is no longer standard practice, nslookup expects FQDNs to be dot terminated. nslookup will append every defined DNS search suffix to an unterminated query before it tries the FQDN by itself. This is great for single-label names, and not so great for multi-label names because too many DNS suffixes can cause a timeout.

Fig. 1 – A screenshot of the Windows DNS suffixes used in this example.

Imagine you want the IP addresses used by bing.com. The system's DNS suffix search list contains contoso.com, fabrikam.com, adatum.com, and northwindtraders.com. You enter "nslookup bing.com" without dot termination and get a DNS timeout error. You start Wireshark, try again, and see the following DNS queries:

Fig. 2 - Trimmed Wireshark output of "nslookup bing.com" from this example.

Standard query 0x0002 A bing.com.contoso.com
Standard query 0x0004 A bing.com.fabrikam.com
Standard query 0x0006 A bing.com.adatum.com
Standard query 0x0008 A bing.com.northwindtraders.com
Standard query 0x000a A bing.com

Then you remember the lessons learned in this article and enter "nslookup bing.com." and you get the IP addresses you expect. The Wireshark trace now shows no unexpected queries.

Other nslookup Quirks

Here are other nslookup quirks you should know about. The first is that nslookup only uses DNS servers for name resolution. The Windows DNS-CR will use the hosts file, DNS client cache, WINS, NetBIOS Name Services, LLMNR, multicast DNS (mDNS), and DNS servers. That's quite a difference in name resolution options.

LLMNR and NetBIOS are going away in the future, in case you have not heard. As is WINS (finally!). Even so, that leaves mDNS, hosts, local cache, and any future name resolutions options added to Windows.

Second, nslookup does not support newer DNS encryption technologies like DNS over TLS (DoT), DNS over HTTPS (DoH), and so on. Therefore, using nslookup could be a security violation in certain environments as it would cause unencrypted traffic on the network. Granted, this functionality can be added in a future update, but there are currently no plans to do so. Resolve-DnsName will leverage DoT and DoH when the Window DNS client is configured to use secure DNS.

Nslookup does not honor DNS policies like the NRPT (Name Resolution Policy Table). A Windows process using DNS-CR will use all system defined DNS policies. Nslookup ignores DNS policies, queries only the system defined DNS servers, and may fail or provide inaccurate results on systems using the NRPT and other DNS policies. This does make nslookup handy when troubleshooting whether DNS policies are working.

The last quirk is DNSSEC, which has its own section later in the article.

Resolve-DnsName: The Windows-Centric Approach

Resolve-DnsName is a PowerShell cmdlet which leverages the Windows DNS-CR by making direct DnsQueryEx() API calls. The use of DnsQueryEx() is what gives the cmdlet all the name resolution options available in Windows. This means that Resolve-DnsName results are Windows accurate name resolution behavior. In other words, if you want to test how a program in Windows does name resolution, then Microsoft recommends using Resolve-DnsName.

Resolve-DnsName provides several versatile options, such as testing queries against only DNS servers (-DnsOnly), bypassing the hosts file (-NoHostsFile), using only the local cache (-CacheOnly), and using only multicast resolvers like mDNS (-LlmnrNetbiosOnly). These parameters make Resolve-DnsName the ideal choice for diagnosing complex name resolution issues in Windows environments.

No dot termination is needed; in case you were wondering. And Resolve-DnsName is much easier to use with PowerShell automation and scripting.

Examples

Here are a few examples for you. Both Resolve-DnsName and nslookup examples are provided, where applicable.

Example 1: Query using DNS only to Cloudflare's public DNS server.

Resolve-DnsName bing.com -DnsOnly -Server 1.1.1.1

nslookup.exe bing.com. 1.1.1.1

This will send a DNS query to 1.1.1.1 asking for the IP addresses of bing.com. By default, both host record types, A (IPv4) and AAAA (IPv6), are requested. Nslookup can do this by entering the DNS server's IP address after the query.

Example 2: Use Cloudflare public DNS to get bing.com AAAA (IPv6) records.

Resolve-DnsName bing.com -Server 1.1.1.1 -Type AAAA

nslookup.exe -type=AAAA bing.com. 1.1.1.1

Same as example one, but without IPv4 addresses.

Example 3: Query a printer over mDNS.

Resolve-DnsName printer01.local -LlmnrNetbiosOnly

Ignore the fact that the parameter says LLMNR. Think of it as -LocalOnly. This parameter uses all broadcast and multicast name resolution methods enabled on Windows and ignores the DNS servers, cache, and the hosts file. Nslookup has no local name resolution capabilities.

Example 4: Perform a DNSSEC query

Resolve-DnsName example.com -DnssecOk

Speaking of DNSSEC…

DNSSEC

nslookup is not DNSSEC aware. For any DNSSEC-related diagnostics, Resolve-DnsName should be your tool of choice in Windows. There are two options to enable DNSSEC: -DnssecCd and -DnssecOk.

Explaining DNSSEC is a wheel I do not intend on reinventing. Here is a series of articles for those who are interested in how DNSSEC works and how to use Resolve-DnsName to test.

https://learn.microsoft.com/en-us/windows-server/networking/dns/dnssec-overview

But It’s So Many Letters!

I know, right! These PowerShell cmdlets names can be long. Go look at some of the Microsoft Graph cmdlet names. Phew!

Let me introduce you to PowerShell profiles and aliases! An alias allows you to create a shortened command. The alias command can be stored in a PowerShell profile. The alias is then added to PowerShell automatically when the profile script runs during session start.

The alias can be rdns (short for Resolve-DnsName), dig (my favorite), or even nslookup. PowerShell can use both an nslookup alias and the nslookup program at the same time. Type nslookup.exe to use the program, and nslookup to use it as an alias of Resolve-DnsName.

Best Practices for Windows DNS Client Troubleshooting

For Windows name resolution troubleshooting, testing, and automation, Resolve-DnsName offers a Windows accurate, easier to use experience with more features and controls. Nslookup is still great for basic DNS resolution, and to test certain situations where you suspect there is a Windows DNS-CR or DNS policy issue.

Learning the fundamental differences between nslookup and Resolve-DnsName will help you avoid common pitfalls and ensure your name resolution troubleshooting efforts are efficient, accurate, and reliable.

A Note About Browsers

It turns out that nslookup is not the only independent DNS resolver on your computer. All major browsers now have a secure DNS option. Last I checked, secure DNS is enabled by default on non-managed systems. A browser with secure DNS enabled will first try to resolve a domain’s IP address by using DNS over HTTPS (DoH) or DNS over TLS (DoT). Browsers use public DNS servers when performing secure DNS.

A plain packet capture will not be able to parse the secure DNS traffic because it will be encrypted. Which is the whole point of secure DNS. The Windows DNS client cache will likewise not contain the browser's secure DNS query results. There are Active Directory and Intune policies which force the big three browsers to use Windows system DNS to avoid unauthorized DNS access.

The Windows 11 DNS client has had support for DoH and DoT for a while now. As for DNS over HTTPS support on Windows DNS Server…stay tuned to the Tech Community Networking blog. Specifically in the February 2026 timeframe.

An Ode to dig Before I Go!

Oh BIND, oh BIND, why have you forsaken Windows? I miss my dig. Yes, I do. I guess WSL2 will have to do.