Same Job, Different Shell Part 5: DNS Lookups and Resolution
DNS problems are the single most common “the network is broken” report that isn’t actually a network problem. Both platforms give you more than one lookup tool, and picking the right one saves a step.
The workhorse: dig vs Resolve-DnsName
Linux, dig is the detailed, script-friendly tool:
$ dig +noall +answer google.com
google.com. 300 IN A 173.194.194.100
google.com. 300 IN A 173.194.194.139
google.com. 300 IN A 173.194.194.101
google.com. 300 IN A 173.194.194.138
google.com. 300 IN A 173.194.194.102
google.com. 300 IN A 173.194.194.113+noall +answer strips dig’s normal verbose header/stats/footer down to just the records, which is what you want once you know the tool works and you’re just after the data. For scripting, go one step further:
$ dig +short google.com
142.251.189.100
142.251.189.138
142.251.189.113
142.251.189.102
142.251.189.101
142.251.189.139+short gives you bare values, one per line, ready to pipe into xargs, awk, or a loop with no parsing required.
Windows, Resolve-DnsName is the structured cmdlet equivalent, and this is real, verified output rather than documentation:
PS> Resolve-DnsName -Name google.com -Type A
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
google.com A 16 Answer 142.250.151.139
google.com A 16 Answer 142.250.151.100
google.com A 16 Answer 142.250.151.113
google.com A 16 Answer 142.250.151.102
google.com A 16 Answer 142.250.151.101
google.com A 16 Answer 142.250.151.138It returns real objects with a TTL field right there, same information dig’s full output gives you (the 300 in the dig +noall +answer block above, 16 here, Google’s actual TTL varies by query), just already parsed into a property instead of a text column you’d have to awk out. Query a specific record type or a specific server the same way dig lets you:
# MX records
PS> Resolve-DnsName -Name microsoft.com -Type MX
Name Type TTL Section MailExchange
---- ---- --- ------- -----------
microsoft.com MX 3600 Answer microsoft-com.olc.protection.outlook.com
# query a specific resolver directly, bypassing whatever the adapter is configured to use
PS> Resolve-DnsName -Name www.bing.com -Server 8.8.8.8 -Type AAAAdig’s equivalent for querying a specific server is @, prefixed directly to the address:
$ dig +short mozilla.org @8.8.8.8The quick, always-there fallback: nslookup
nslookup exists on both platforms, does the same job, and is the one worth reaching for when you just need a fast answer and don’t want to remember flags.
Linux:
$ nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.250.152.102
Name: google.com
Address: 142.250.152.101Windows:
C:\> nslookup google.comproduces near-identical output, same “Server/Address” header showing which resolver answered, same “Non-authoritative answer” label. This is the one command in the whole series that’s genuinely close to identical on both platforms, because Windows’ nslookup.exe and most Linux distributions’ nslookup both trace back to the same BIND-era tool lineage.
There’s also host on Linux, a third option nobody asks for but which gives the tersest possible answer when that’s all you want:
$ host google.com
google.com has address 74.125.132.138
google.com has address 74.125.132.102
google.com has IPv6 address 2607:f8b0:4001:c10::8b
google.com mail is handled by 10 smtp.google.com.One line per record, address and MX together, no server header, no verbosity. Windows has no direct equivalent; the closest is Resolve-DnsName ... | Select-Object -ExpandProperty IPAddress.
Before you query anything remote: check the local cache first
This is the step people skip, and it’s the fastest possible DNS diagnostic on either platform, because it doesn’t touch the network at all.
Windows keeps a visible, manageable local resolver cache:
C:\> ipconfig /displaydnsdumps every cached record, name, type, TTL remaining, and the actual data, all client-side, answered from the local resolver cache service (Dnscache). If a record just changed at the authoritative source but a client is still acting on the old value, this is where to look before blaming the network:
C:\> ipconfig /flushdnsclears it, forcing the next lookup to go out fresh.
Linux doesn’t have one universal answer here, it depends on what’s actually running the resolver on that box. Modern systemd-based distros with systemd-resolved active have the same kind of visible, manageable cache:
$ resolvectl status
$ resolvectl query google.com
$ resolvectl flush-cachesBut plenty of Linux boxes, containers especially, run no local caching resolver at all, every dig/nslookup/application lookup goes straight to whatever’s in /etc/resolv.conf with no client-side cache in between. This sandbox is one of those: no resolvectl binary at all, no caching layer, every dig call above hit the upstream resolver fresh. Where Windows always has a cache to check, Linux’s answer to “is this a caching issue” is genuinely “it depends what’s installed”, and checking resolvectl status (or systemd-resolve --status on older systemd) is how you find out rather than assume.
Quick reference
| What you want | Linux | Windows |
|---|---|---|
| Detailed query, script-friendly | dig +short <name> | Resolve-DnsName -Name <name> |
| Quick manual lookup | nslookup <name> | nslookup <name> |
| Query a specific record type | dig <name> MX | Resolve-DnsName -Name <name> -Type MX |
| Query a specific server directly | dig <name> @<server> | Resolve-DnsName -Name <name> -Server <server> |
| Terse address-only output | host <name> | (Resolve-DnsName <name>).IPAddress |
| View local resolver cache | resolvectl query <name> (if resolved is running) | ipconfig /displaydns |
| Flush local resolver cache | resolvectl flush-caches | ipconfig /flushdns |
What’s next
Part 6 covers active connections and sockets: ss and netstat against netstat and Get-NetTCPConnection, once name resolution and routing both check out, the next question is usually what’s actually connected right now.