- SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords - Tue, Dec 5 2023
- New Group Policy settings in Windows 11 23H2 - Mon, Nov 20 2023
- Windows Server 2025 will support SMB over QUIC in all editions - Fri, Nov 17 2023
nslookup is essentially a DNS client that can be used to check the name resolution. For a simple query of a hostname, you can pass the hostname as a parameter:
nslookup dc.contoso.com
Interactive mode of nslookup
For operations that require multiple commands, the utility is usually used in interactive mode. To do so, you invoke it without arguments and then land on a prompt. By typing Help, you can display all available commands.
Command overview for nslookup
If you simply type the name of a host here, nslookup returns the A or AAAA entry of the host. Via commands such as
set type=CNAME
you can also query other records, such as CNAME, MX, NS, or PTR.
In dual-stack environments where IPv6 is not properly maintained and where the clients do not have a correct DNS server configured for IPv6, the Windows implementation of nslookup always fails. In this case, it does not make another attempt via IPv4.
If a DNS server cannot be reached via IPv6 nslookup fails with a timeout
Resolve-DnsName
PowerShell has its own cmdlet that can perform the tasks of nslookup. Unlike the traditional utility, it does not provide an interactive mode; rather, you supply Resolve-DnsName all the necessary information as parameters.
Another difference is that the cmdlet does not fail over an invalid IPv6 configuration, but rather follows up with a query over IPv4.
In the simplest case, you invoke the cmdlet with the desired hostname as a parameter:
Resolve-DnsName dc.contoso.com
If you want to direct the query to a specific DNS server, then specify it using the Server parameter:
Resolve-DnsName dc.contoso.com -Server 192.168.0.1
As an alternative to the IP address, you can also use the host name of the DNS server.
If you want to narrow down a name resolution problem to DNS and prevent it from being done via NetBIOS in the event of failure, then add the DnsOnly switch:
Resolve-DnsName -Name dc.contoso.com -DnsOnly
A hosts file can also interfere with investigating DNS problems. It can be ignored with the NoHostsFile switch:
Resolve-DnsName -Name dc.contoso.com -NoHostsFile
Conversely, you can use NetbiosFallback or LlmnrFallback to ensure that NetBIOS or Link Local Multicast Name Resolution (LLMNR) are applied if DNS resolution fails.
Invoking Resolve DnsName with different parameters
Finally, it is even possible to examine only name resolution based on these legacy protocols by using the LlmnrOnly or LlmnrNetbiosOnly parameters. The CacheOnly switch also provides an interesting option if a DNS server is currently unreachable or the cache contains outdated entries.
Like nslookup, Resolve-DnsName retrieves the A or AAAA record for the host by default. You can also use the Type parameter to query other DNS entries.
Summary
The long-standing nslookup still serves its purpose, and not only for the simple resolution of a hostname passed to it as a parameter. It also provides an interactive mode where you can issue multiple commands that don't need to be preceded by nslookup each time.
Subscribe to 4sysops newsletter!
PowerShell offers more options with Resolve-DnsName, which can also examine older Microsoft protocols for name resolution. It can also specifically hide the hosts file or use only the cache.
nslookup is available back to Windows XP.
This powershell applet is not.
Pity.
Like so many other things “PowerShell” it orphans perfectly good functions such as nslookup because the new toys are bound to powershell versions not available on older platforms.
There are many valid reasons why older platforms remain in use.
I don’t know why you say PowerShell “orphans” nslookup. Nslookup is still available to use, and actually works very well from a PowerShell prompt as well as a CMD prompt. If you feel that PowerShell versions are not available on older platforms, I can only assume you never tried to install a newer version of PowerShell on those machines.
You missed the entire point of my comment.
This article is not about running nslookup under PowerShell.
It is about a new PowerShell cmdlet in place of nslookup.
I have zero interest in opening a PowerShell session just to run nslookup which I can do just as well with CMD, which is installed on EVERY version of Windows.
A number of PowerShell cmdlets are not available on WinXP or Win7 because the versions that contain them won’t run on those platforms.
I like PowerShell just fine, and write a great deal with it.
I still use nslookup because it is “always there” when I need it.
Honestly the biggest problem with Resolve-DnsName is how limited its availability is. Because it’s part of Windows PowerShell only, it’s not available on Server Core, Azure Cloud Shell / Function Apps etc or other operating systems.
It’s a useful cmdlet especially in a script, but it would be far more useful if I could depend on it to be available where I’m working.
The idea of leaving LLMNR seems like a bad idea.
https://www.blackhillsinfosec.com/how-to-disable-llmnr-why-you-want-to/
The primary benefit to Resolve-DNSName compared to nslookup is that you’re getting an object back that you can process in your scripts without having to try and parse the text. You can retrieve the IPv4 & IPv6 addresses simultaneously, get the record types etc. It’s a very rich object that gets returned.
David F.