Category: cybersecurity

An IP scanner walks a range of addresses on a network you administer, records which hosts answer, and returns what it can learn about each one: address, hostname, MAC address, and sometimes open ports or shared folders. That output becomes the raw material for asset inventory, rogue device detection, and everyday troubleshooting when a printer vanishes or a subnet fills up faster than expected.

Run discovery only against ranges you own or have written authorization to test, start with a passive or ping-level sweep before anything intrusive, and treat every result as a hypothesis until a MAC address or hostname confirms the asset. That sequence keeps scans defensible and keeps your inventory honest.

PacketTools was built by a network and security engineer with more than 28 years of hands-on experience in enterprise IT, and the same diagnostic habits that verify VPNs and analyze routing in production apply directly to device discovery. By the end of this, you will be able to pick a discovery method that fits your environment, read the output without guessing, and know which findings deserve a follow-up before you touch a switch port.

What Device Discovery Reveals on a Network

https://www.youtube.com/watch?v=zYdRruF1g1w

Discovery answers one question well: which addresses in a defined range currently respond. Everything else, hostname, vendor, operating system, service banner, is enrichment layered on top of that reachability signal, and each layer has its own failure mode.

From IP Address to Hostname and MAC Address

A network scanner starts with an address and works outward. The IP tells you where the host sits in the subnet. Reverse DNS may return a hostname, and on the local segment the ARP table gives you a MAC address whose first three bytes identify the vendor.

That vendor prefix is the most useful field in a LAN scanner result. A MAC beginning with an Axis or Hikvision OUI on a corporate VLAN reads very differently from an Apple or Dell prefix, even before you know the device name.

Where hostname resolution fails, the MAC often still lands. Where both fail, you have an address that answers and nothing more, which is a legitimate finding worth recording as such.

Why a Reachable Host Is Not Always an Identified Asset

Reachability and identity are separate data points. A host can reply to ICMP while blocking every port, refusing NetBIOS, and having no PTR record, leaving a row in your network inventory that says “something is here.”

Firewalled endpoints, hardened Linux hosts, and IoT sensors with minimal stacks all produce this. Devices behind a router relative to your scan point show a MAC address belonging to that router, not the endpoint, which quietly breaks vendor identification.

IPv4, IPv6, and Subnet Boundaries

Scan scope follows the subnet, and this is where most incomplete inventories originate. A /24 sweep covers 254 usable hosts; a /16 covers over 65,000 and takes correspondingly longer.

IPv6 changes the math entirely. A /64 holds 18 quintillion addresses, so brute-force sweeps are impractical, and a network IP scanner working in IPv6 relies on neighbor discovery, multicast, DHCPv6 leases, or DNS records instead of enumeration. Dual-stack hosts frequently appear twice, once per address family, and reconciling those into one asset record is manual work in most tools.

How Authorized Discovery Methods Work

Every discovery method sends probes and waits for responses, and the choice of probe determines what you find and what you miss. Ping sweeps find cooperative hosts, ARP finds everything on the local segment, SNMP interrogates managed gear directly, and port probing fills in service detail once scope and permission are settled.

Ping Sweeps and Their Blind Spots

An ICMP echo sweep is the fastest and least intrusive way to establish which addresses are live. Nmap’s -sn flag does exactly this, and it doubles as a sanity check that you are pointed at the right range before running anything heavier.

The blind spot is predictable: hosts configured to drop ICMP appear dead. Windows endpoints with the default firewall profile, hardened servers, and many appliances all fall into that bucket. A ping sweep that returns 40 hosts on a segment you know has 60 endpoints is telling you about your probe, not your network.

Our ping test is useful for the reverse case, confirming reachability and round-trip behavior for a single host you already know about.

ARP, NetBIOS, and Local Network Visibility

On your own broadcast domain, ARP is the honest method. A host cannot participate in IPv4 on the segment without answering ARP, so arp-scan and equivalent discovery find devices that ignore ICMP completely.

The constraint is that ARP stops at the router. Off-segment ranges need a scan point inside that segment or a different technique.

NetBIOS adds names on Windows-heavy networks, resolving workstation and workgroup identity where DNS records are missing. Older SMB-speaking devices and network printers often respond here when nothing else identifies them.

SNMP Polling for Managed Infrastructure

SNMP gives you the richest data on switches, routers, printers, and UPS units, because you are reading the device’s own MIB instead of inferring from packet behavior. Interface tables, ARP caches, and neighbor entries pulled from a core switch reveal hosts a sweep never touched.

Use SNMPv3 with authentication and encryption. Community strings of public on production gear are a finding in their own right, not a convenience.

Port and Service Probing in Approved Environments

Port scanning follows host discovery: once you know an address is live, you determine which ports respond and what services sit behind them. HTTP and HTTPS management interfaces, FTP on legacy transfer boxes, SSH, and SMB shares are the common finds, and each produces an ip-port list you can compare against approved baselines.

Two rules keep this safe. Get the authorization in writing with the target ranges named, and slow the timing on fragile equipment. Industrial and medical devices have been knocked offline by aggressive default timing, which is why conservative timing and identity-oriented scripting are standard practice for ICS and OT segments. Feed results into network monitoring so changes surface between scans.

How to Read and Validate Scan Results

Scan results are evidence, not conclusions. Validation means separating “this device is unrecognized” from “this scan lacked the access to identify it,” then reconciling the surviving rows against what your records claim should exist.

Distinguishing Unknown Devices From Incomplete Data

Start with the fields that are blank. An entry with an IP, no hostname, no vendor, and no open ports usually means the probes were blocked, not that the device is exotic.

Re-run the same address with a second method before escalating. An ARP query on the local segment, an SNMP poll of the switch the host connects to, or a NetBIOS name request each attacks the gap from a different angle. Vendor OUI lookups on the MAC often resolve identity when everything else stays quiet.

Then check the wired path. Switch MAC address tables map a MAC to a physical port, which turns an abstract row into a cable you can trace. That step converts more unknowns than any additional scan flag.

Finding Duplicate Addresses and Stale Records

Two hosts answering for one IP produces intermittent, maddening symptoms: sessions that drop mid-transfer, ARP entries that flip vendor prefixes between polls. Compare MAC addresses across consecutive scans of the same range and duplicates surface immediately.

Stale records run the other direction. Addresses in your inventory that no longer respond, DHCP reservations for decommissioned hardware, DNS entries pointing at reassigned IPs. Each one is a future misdiagnosis, and each one is cheap to clear once you have two scans to compare.

Timestamp every export. Scans run at 3 a.m. and 3 p.m. on the same subnet return different host counts, and without timestamps you cannot tell drift from noise.

Turning Discovery Data Into Asset Management Evidence

Discovery becomes useful for asset management when each row carries provenance: scan date, method used, scope, and who authorized it. Continuous asset visibility of this kind is a prerequisite for a never trust, always verify model, which is why zero trust programs start with inventory work.

Reconcile the export against your CMDB, tag unexplained hosts with an owner and a due date, and keep the raw file. When a network security question comes up six months later, dated evidence settles it.

Which Tool Fits the Environment?

Tool selection follows the question you are answering: a one-off reachability check, a repeatable subnet sweep for a spreadsheet, a scripted scan feeding a pipeline, or a platform that tracks assets without you starting anything.

	Browser tools	Angry IP Scanner	Nmap	Inventory platforms
Install required	No	Yes	Yes	Yes, plus agents/collectors
Platforms	Any browser	Windows, Mac, Linux	Windows, Linux, macOS	Server or SaaS
Scriptable output	Limited	Multiple export formats	Full (XML, grepable)	API and reporting
Best for	Single-host checks	Fast range sweeps	Precise, documented scans	Continuous inventory
Cost	Free	Free, open source	Free, open source	Licensed

Browser-Based Checks vs. Local Discovery Software

Browser tools handle the checks that do not require touching every address in a range: confirming your public address, resolving a record, testing a certificate, verifying reachability from outside the LAN. PacketTools runs these in real time with no sign-in and no logging of IPs, queries, or test data, which matters when the target is a client’s production edge.

Sweeping an internal /24 needs software on a host inside that subnet. No browser can send ARP requests to your LAN, so local discovery software remains the tool for full-subnet enumeration. The what is my ip check is the fastest way to establish which public address your scan traffic will originate from before you request authorization.

When Command-Line Control Matters

Nmap earns its place when you need exact control over probe type, timing, and output format. nmap -sn 10.10.20.0/24 for a discovery-only sweep, timing templates to throttle fragile segments, XML output that parses cleanly into a report.

That precision is also documentation. A saved command plus its XML output proves what you ran, against what, and when. Ethical practice here is explicit: scan only networks you own or have written permission for, since unauthorized scanning can violate the Computer Fraud and Abuse Act.

Desktop Options for Windows, macOS, and Linux

Angry IP Scanner is the cross-platform default: free, open source, runs on Windows, Mac, and Linux, scans address and port ranges, exports to several formats. It is the tool to reach for when someone asks for a device list in the next ten minutes.

Famatech’s Advanced IP Scanner is Windows-only and adds shared folder access plus RDP and Radmin launch shortcuts from the results grid. SoftPerfect Network Scanner runs on Windows, macOS, and Linux, and retrieves device detail over WMI, SNMP, HTTP, SSH, and PowerShell, which suits mixed environments where one protocol is never enough.

Fing covers the mobile and home side, identifying device brand, model, and OS during the scan.

When Continuous Inventory Platforms Are the Better Fit

Manual scans go stale the moment they finish. Platforms like Lansweeper suit environments where devices join and leave daily, agents and credentialed collection fill in software inventory, and audit trails need to exist without anyone remembering to run a sweep. Lansweeper does not publish flat pricing publicly; licensing scales with asset count.

The tradeoff is deployment weight and credential management. For a 40-device office, a scheduled Angry IP Scanner export into a dated spreadsheet holds up fine.

Using Discovery Data Safely in Home and Managed Networks

Authorization comes before the first packet, and what you do with the output matters as much as how you collected it. Managed networks need documented scope and change-window timing; a home LAN needs a baseline you can compare against next month.

A Permission-First Process for Managed Networks

Written authorization naming the exact CIDR ranges, the scan window, the methods permitted, and a named contact who can stop the scan. Network administrators who skip this step end up explaining themselves to a security team mid-scan.

Then work in stages. Passive collection and SNMP polling first, ICMP discovery second, port probing last and only within the approved scope. Notify the monitoring team so your sweep does not open an incident ticket, and avoid production change freezes.

Record what you ran. Command, timestamp, operator, and output file, stored alongside the authorization.

A Practical Home LAN Inventory Example

Start by finding your subnet: check your router’s LAN page or run ipconfig on Windows or ip addr on Linux. A typical home range is 192.168.1.0/24.

Scan that range with Angry IP Scanner or Fing and export the results. Then walk the physical space and match each responding host to something you can see: thermostat, TV, doorbell, tablet in a drawer.

Rename anything identifiable in your router’s DHCP table and set static reservations for the printer and NAS. That single pass converts a wall of addresses into a list you can compare against, and it is the fastest way to find the smart plug you forgot about. When a device shows up in the scan but the internet is unreachable from it, our guide on wifi connected but no internet covers the layered checks.

What to Check After an Unexpected Device Appears

Do not start with a takedown. Pull the MAC address and look up the vendor prefix, since most surprise devices resolve into a known brand of streaming stick, smart bulb, or guest phone.

If it stays unidentified, find its switch port or check whether it associated over wireless, then look at what it talks to. A device beaconing to unfamiliar destinations is a different problem from one sitting idle.

Isolation before removal: move it to a guest VLAN or block it at the firewall while you confirm ownership. Rotate the Wi-Fi PSK if wireless access is the likely entry point, and check whether RDP or Radmin is reachable from that segment.

Extending Troubleshooting With PacketTools

Discovery tells you a host exists; the follow-up questions are about whether it works. Our free network tools cover the layers a sweep does not touch, with no sign-in and nothing logged.

When a host responds to a scan but its name will not resolve, the dns propagation checker and dns lookup failed walkthrough narrow it down. For path problems between segments, how to trace a route explains reading hop-by-hop output. Domain-wide checks, DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL, run together in the super tool.

Building Reliable Visibility Without Overreaching

An IP scanner earns its keep when the scope is authorized, the method matches the segment, and the output gets validated before anyone acts on it. ARP finds what ICMP misses on the local wire, SNMP fills in managed infrastructure, and port probing waits for written permission naming the ranges.

Read results as evidence with gaps: blank hostname fields point at blocked probes more often than mystery hardware, and a MAC vendor lookup or a switch port trace resolves most of what a network scan leaves ambiguous. Timestamp exports, compare consecutive runs, and clear stale records as you go.

Pick the lightest tool that answers the question. A browser check for a single host, Angry IP Scanner for a subnet list you need this afternoon, Nmap when the command and its output have to stand as documentation, a continuous platform when devices change faster than you can schedule sweeps. Keep the authorization filed with the results, and your network security and asset management records stay defensible.

A DNS lookup failed message means one specific thing: the resolution chain that turns a domain name into an IP address broke somewhere between your stub resolver and the authoritative nameservers. Everything else, the browser error string, the application timeout, the failed API call, is downstream noise. Your job is to find which hop stopped answering.

Work the resolution path in order (client cache, stub resolver, recursive resolver, authoritative nameserver, zone data) and a DNS lookup failure narrows to a single fault domain in under five minutes. That order matters because each layer can mask the one behind it, and flushing a cache before you know whether the domain even delegates correctly wastes the outage window.

PacketTools was built around exactly this workflow. The same DNS Lookup, DNS Propagation Checker, and SuperTool queries used here run in production networks to verify delegation, compare resolver answers, and confirm records before a change goes live. No sign-in, no logging of your queries, no stored test data.

By the end, you will be able to read an NXDOMAIN, a SERVFAIL, and a bare timeout as three different diagnoses, and know which one belongs to you and which one belongs to the domain owner.

What the Error Reveals About the Resolution Path

The exact response code your resolver returns tells you how far the query traveled before it died. A domain that returns NXDOMAIN reached authoritative DNS and got a definitive “no such name.” A query that times out may never have left your NIC.

How a Recursive Resolver Reaches Authoritative DNS

Your stub resolver hands the query to a recursive resolver, which walks the hierarchy from root to TLD to the domain’s nameservers.

The recursive resolver asks a root server for .com nameservers, asks those for the domain’s NS records, then asks the authoritative nameserver for the A record, AAAA record, or CNAME record you requested. Each step is cached against its TTL.

Break any link and the symptom changes. A missing NS record at the parent zone kills the referral. A dead authoritative host kills the final answer. A broken CNAME target resolves halfway and then returns nothing usable.

NXDOMAIN vs. SERVFAIL vs. Timeout Responses

These three responses point at three different owners of the problem.

Response	What it means	Where to look
NXDOMAIN	Authoritative DNS confirms the name does not exist	Typo, deleted record, expired domain
SERVFAIL	Resolver tried and could not complete the lookup	DNSSEC validation failure, broken delegation, unreachable nameserver
Timeout	No response at all within the grace period	Blocked UDP port 53, unreachable resolver IP, firewall drop

SERVFAIL is the one engineers misdiagnose most. It is a resolver-side failure report, so the domain can be perfectly configured while your validating resolver rejects the chain.

Why 504 DNS Lookup Failed Is a Different Failure Mode

A 504 DNS lookup failed comes from a proxy, CDN edge, or gateway, telling you its resolver could not resolve your origin hostname.

Your workstation resolves the site fine because you are hitting the edge, which then fails to look up the backend. Check the origin hostname in your CDN configuration, the origin’s A record, and whether the origin nameservers answer queries from outside your network.

Is the Fault Local, Network-Wide, or Domain-Side?

Scope the blast radius before touching a single setting. One device failing, every device on the LAN failing, and one domain failing everywhere are three separate investigations with almost no overlap in remediation.

What It Means When Only One Device Fails

A single failing host points at that host’s DNS configuration, cache, or a local override.

Test the same name from a phone on mobile data and from a second machine on the same subnet. If both succeed, the fault sits in the endpoint’s resolver settings, a stale cache entry, a hosts file line, or a VPN client that rewrote the DNS servers on the network adapter.

Windows checks its cache first, then the hosts file, then queries the DNS server, according to Microsoft’s client name resolution guidance. A stale hosts entry produces zero DNS traffic on the wire, which is why packet captures look empty during these failures.

How to Separate Wi-Fi and ISP Problems From DNS

Ping an IP address directly. If ping 1.1.1.1 succeeds and name resolution fails, connectivity is fine and DNS is the problem.

When the ping also fails, you are chasing a Wi-Fi, modem, or ISP path issue, not resolution. That is the difference between a resolver fault and a Wi-Fi connected but no internet condition, and the fixes share nothing.

DHCP hands out ISP DNS by default. When an ISP resolver has a partial outage, some names resolve and others fail, which reads like a random site problem until you compare against a public resolver.

When One Domain Fails but Other Sites Resolve

A single domain failing across multiple networks and resolvers is a domain-side fault.

Check registration status and nameserver delegation first. An expired domain, a registrar hold, or nameservers that were changed at the registrar but never populated at the DNS provider all produce the same user-facing failure.

Recent record changes bring TTL into it. A DNS propagation delay means old cached answers persist for the length of the previous TTL, and CDN edges hold their own cached views independently.

Run the First DNS Tests Before Changing Settings

Diagnose before you remediate. Four minutes of resolver comparison and a dig +trace will tell you whether the fault is your resolver, the transport path, or the domain’s zone, and that answer determines every step after it.

Compare Local, Google, Cloudflare, and Quad9 Resolver Results

Query the same name against your configured resolver and three public DNS servers, then compare.

• Google DNS: 8.8.8.8 and 8.8.4.4
• Cloudflare DNS: 1.1.1.1 and 1.0.0.1
• Quad9: 9.9.9.9

If your local resolver fails while all three public resolvers answer, the fault is your resolver or ISP DNS. If every resolver fails identically, the domain or its delegation is broken. If public resolvers work and your local one returns a different answer, suspect split DNS or interception.

Quad9 filters known-malicious domains, so a name that resolves on 1.1.1.1 and returns NXDOMAIN on 9.9.9.9 is a reputation block, not a configuration error.

Use nslookup and dig to Identify the Break

dig gives you the status line and the full chain; nslookup ships on every Windows box.

dig example.com A +short
dig @8.8.8.8 example.com A
dig example.com NS
dig +trace example.com

+trace walks root to TLD to authoritative, and where it stops is where delegation breaks. Failing early in the trace points at domain registration or the parent zone’s NS records.

On Windows, nslookup example.com 8.8.8.8 forces a specific server. Note that nslookup contacts only the primary configured DNS server, so on a NIC with four resolvers listed it will report failure even when a secondary would have answered. Windows uses nslookup while macOS and Linux use dig for the same class of test.

Read the status: field in dig output. NOERROR with an empty ANSWER section means the name exists but the record type you asked for does not.

Check Reachability and the DNS Path With Ping and Traceroute

DNS rides UDP port 53 with TCP fallback for large responses, so confirm that transport actually works.

Ping the resolver IP. A resolver that does not answer ICMP still may serve DNS, so follow with dig @<resolver-ip> example.com to test port 53 directly. Run a ping test against the resolved IP once you have an answer to separate resolution from reachability.

Traceroute the resolver address when queries time out on an internal DNS server. Path asymmetry, a firewall hop that drops UDP, or an MPLS re-route shows up in the hop list. Our guide on how to trace a route covers reading those hops properly.

Validate a Domain With PacketTools DNS Lookup and SuperTool

Command-line tools show you what your vantage point sees. External validation shows what the rest of the internet sees.

The PacketTools DNS Lookup runs the query from outside your network, so a name that fails locally and resolves externally confirms the fault is inside your perimeter. SuperTool bundles DNS, MX, SPF, DKIM, DMARC, blacklist, and SSL checks into a single domain run, which is faster than firing six separate queries when a domain’s records are suspect.

Nothing is logged. No IPs, no queries, no test data, no sign-in.

Fix Endpoint Resolver and Cache Problems

Endpoint fixes are cheap and reversible, which is why they come after diagnosis and before anything touching production DNS. A corrupted cache, a stale static resolver entry, or a VPN client override accounts for most single-machine failures.

Clear a Corrupt DNS Cache on Windows, macOS, and Linux

Flush the cache when a record changed recently and your machine still returns the old IP address.

• Windows: ipconfig /flushdns from an elevated Command Prompt
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): sudo resolvectl flush-caches
• Linux (nscd): sudo systemctl restart nscd

Verify after flushing with dig and check the TTL value in the response. A TTL counting down from the record’s full value means you received a fresh authoritative answer; a low odd number means you hit a cache again.

Google Chrome keeps its own cache at chrome://net-internals/#dns. Clear that separately, since flushing the OS cache leaves it untouched.

Verify DHCP and Static DNS Configuration

Check what DNS servers the adapter is currently using before assuming DHCP delivered them.

Run ipconfig /all on Windows or resolvectl status on Linux. A static entry pointing at a decommissioned internal DNS server is a common leftover from a lab build or an old migration.

Multiple unreachable servers listed ahead of a working one cause resolution to take roughly four seconds while the client cycles through the list. Applications time out before DNS does. Remove dead entries in the TCP/IPv4 properties rather than adding more.

Reset the Windows Network Stack Only When Needed

Reserve stack resets for cases where the adapter configuration looks correct and queries still never leave the machine.

netsh winsock reset
netsh int ip reset

Both require a reboot and will clear proxy settings, static routes, and any LSP entries installed by security software. Capture the current config first. This is the step that fixes DNS_PROBE_FINISHED_BAD_CONFIG conditions when nothing lighter has, and our walkthrough on DNS_PROBE_FINISHED_BAD_CONFIG covers the sequence in more detail.

Check Browser, Hosts File, VPN, and Proxy Overrides

Something between the application and the resolver is rewriting your query more often than you would expect.

Inspect C:WindowsSystem32driversetchosts or /etc/hosts for leftover entries. A hosts entry produces an answer with no DNS traffic on the wire at all.

Then check for a VPN client that pushed its own DNS servers, an Android Private DNS profile still pointed at a decommissioned DoT host, and browser-level DNS-over-HTTPS that bypasses your corporate resolver entirely. Clearing cookies fixes nothing here; the override is at the resolver layer.

Resolve Network, Security, and Authoritative DNS Faults

Once the endpoint is clean, the remaining faults live in the transport path or the zone itself. Blocked port 53, split-horizon views that leak, broken delegation, and DNSSEC chain failures each produce distinct signatures.

Allow DNS Transport Through Firewalls, Filters, and Relays

An outbound rule blocking UDP port 53 produces a timeout with zero DNS traffic reaching the server.

Microsoft documents this precisely: with UDP 53 blocked, Resolve-DnsName returns an operation timeout and a Wireshark trace on the client shows no outbound DNS at all. Mirror the switch port to confirm whether the packet ever left the host.

Allow TCP 53 as well. Large responses, DNSSEC records, and zone transfers fall back to TCP, and a UDP-only rule breaks them selectively. Content filters and router DNS relays add another failure point when the relay itself points at a dead upstream.

Diagnose Split DNS on Corporate Networks and VPNs

Split DNS breaks when the client resolves an internal name against an external resolver, or the reverse.

Compare dig @<internal-dns> intranet.corp.example with dig @1.1.1.1 intranet.corp.example. Internal-only zones return NXDOMAIN publicly by design, so a public NXDOMAIN on an internal name is correct behavior and tells you the query went to the wrong resolver.

Check the VPN’s DNS suffix search list and split-tunnel rules. A long suffix search list makes the client append each domain in order, adding seconds of latency before the correct query is even sent.

Repair Delegation, Zones, and Missing Records

Delegation faults show up as SERVFAIL or an early stop in dig +trace.

Query the parent zone for NS records with dig example.com NS @<tld-server> and compare against what the DNS provider actually serves. Registrar nameservers and provider nameservers must match exactly.

Then confirm the record itself exists. An A record deleted during a migration, a CNAME pointing at a hostname that no longer resolves, or an AAAA record for an IPv6 address that is not routed all produce failures for clients that prefer that record type.

Handle DNSSEC Failures and Propagation Safely

A DNSSEC validation failure returns SERVFAIL on validating resolvers while non-validating resolvers answer normally.

Test with dig +cd example.com to disable validation. An answer with +cd and SERVFAIL without it confirms a broken chain, almost always a DS record at the registrar that no longer matches the zone’s DNSKEY after a key rollover.

Lower TTLs to 300 seconds at least 24 hours before a planned change, then verify the new records across regions with a propagation check before restoring the original TTL. Testing changes on a staging domain that mirrors production is standard practice, as outlined in safe pre-launch DNS testing.

Turn DNS Evidence Into the Right Next Action

Every DNS lookup failed error resolves into one of four owners: your endpoint, your network path, your resolver, or the domain’s authoritative DNS. The response code and the resolver comparison identify which one before you change anything.

Work the sequence. Compare your resolver against 8.8.8.8, 1.1.1.1, and 9.9.9.9. Run dig +trace to see where delegation stops. Flush the cache only when a record changed recently. Reset the Windows stack only when queries never leave the NIC.

For domain-side faults, verify delegation and records externally with the PacketTools DNS Lookup and confirm timing with the propagation checker before you tell a stakeholder the change is live. When a broader outage is in play, our network troubleshooting and DNS server not responding guides pick up where resolution testing leaves off.

Keep the four public resolver IPs and dig +trace in your runbook. Those two things answer the ownership question faster than any log dive.

When Chrome throws DNS_PROBE_FINISHED_BAD_CONFIG, the browser is telling you it asked the resolver for an address and the resolver configuration on that machine or network was broken enough that the query never produced a usable answer. The site is probably fine. Your DNS path is not.

Work the problem in this order: confirm the domain resolves publicly, flush the local resolver cache, verify the adapter’s DNS server addresses, then rule out VPN, proxy, and security software. Most tickets close somewhere in the first two steps, and the remaining ones almost always trace back to a static DNS entry someone set months ago and forgot about.

At PacketTools we use these same diagnostics in production networks to verify VPNs and analyze routing, so the sequence below is the one that survives contact with real endpoints. You will finish with a repeatable triage path you can hand to a junior tech, plus a way to prove whether the fault sits on the device, the network, or the domain itself.

What the Error Indicates During DNS Resolution

This error fires when the stub resolver on the device cannot complete a DNS lookup because of the configuration it was handed, whether that came from DHCP, a static entry, a VPN client, or a router. The domain name may exist perfectly well in public DNS while the client still fails, which is what separates this code from a genuine missing-record failure.

How a Domain Name Becomes an IP Address

Chrome hands the domain name to the operating system’s resolver. The resolver checks its cache, then queries the configured DNS server, which walks the domain name system hierarchy until an authoritative name server returns an A record with an IPv4 address (or AAAA for IPv6).

Only after the browser holds that IP address can it open a TCP connection to the web server. Break any link in that chain, the DNS server addresses, the route to them, or the cached entry, and the URL never gets a destination.

Why a Bad Configuration Differs From NXDOMAIN

NXDOMAIN means an authoritative server answered and said the non-existent domain has no record. Bad config means the answer never came back cleanly at all.

Signal	Bad Config	NXDOMAIN
Who answered	No usable reply from resolver	Authoritative server replied
Domain exists	Usually yes	No
Fault location	Device or network	DNS records
Fixed by changing resolver	Frequently	No

That distinction matters when you triage. Bad config points to misconfigured settings at the device or network level, so stop editing zone files and start checking adapters.

How the Message Appears Across Browsers and Operating Systems

Chrome shows the literal string. Firefox reports “We’re having trouble finding that site,” Safari says it cannot find the server, and Opera renders the same Chromium text since it shares the engine.

The underlying failure is identical on Windows, macOS, Linux, Android, and iPhone. Only the wording changes, so never assume a browser-specific bug when a second browser on the same endpoint fails too.

Is the Failure on the Device, Network, or Domain?

Isolate the fault domain before you touch a single setting: test more than one hostname, test a second network connection, and query both the configured resolver and a public one. Three minutes of scoping saves you from resetting a network stack that was never broken.

Test Multiple Domains and a Second Network Connection

Load three unrelated domains. If every one fails, the resolver path is broken; if only one fails, look at that domain’s DNS records or a filtering policy.

Then move the endpoint to a phone hotspot. Working over cellular and failing on the office Wi-Fi or Ethernet points at the router, the VPN, or the internet service provider’s resolvers. Failing on both keeps the fault on the device.

Query the Configured Resolver and a Known Public Resolver

Open a command prompt or terminal and query directly, bypassing the browser entirely:

nslookup packettools.com
nslookup packettools.com 8.8.8.8

On Linux or macOS, dig @1.1.1.1 packettools.com +short does the same job. When the second query returns an address and the first times out, the configured DNS server is the problem, not the domain. That pattern also produces the classic DNS server not responding symptom on the same box.

Keep the public DNS servers handy: Google DNS at 8.8.8.8 and 8.8.4.4, Cloudflare at 1.1.1.1 and 1.0.0.1.

Use PacketTools to Check Public DNS Records Independently

Local tools inherit local breakage. Run the lookup from outside your network with the DNS propagation checker to see what resolvers worldwide return for the domain.

If public results come back clean and consistent, the domain’s DNS records are fine and your remaining work is entirely client-side. PacketTools logs no IPs, queries, or test data, which makes it safe to run against internal-facing hostnames during a live incident.

Restore Basic Network Connectivity First

Before editing DNS settings, confirm the endpoint holds a valid lease and can reach its gateway. A device with a 169.254.x.x address or a missing default route will throw DNS errors that have nothing to do with DNS configuration.

Restart the Modem, Router, and Affected Endpoint

Power off the modem and wi-fi router, wait sixty seconds, bring the modem up first and let it sync before powering the router. Reboot the endpoint last.

This clears the router’s own DNS forwarder cache and forces a fresh DHCP lease. One recurring report on Microsoft Q&A describes the error hitting three home PCs every other day, fixed each time by a router reset, which is the signature of a failing forwarder rather than a client fault.

Confirm DHCP Has Supplied a Valid Address and Gateway

Check the assigned address, then renew it:

ipconfig /all
ipconfig /release
ipconfig /renew

On macOS, use System Settings > Network > Details > TCP/IP > Renew DHCP Lease. On Linux, sudo dhclient -r && sudo dhclient on the relevant network adapter.

Verify three things in the output: a routable IPv4 address, a default gateway on the same subnet, and DNS server entries that make sense for the network. Ping the gateway to confirm layer 3 works before blaming name resolution.

Identify Router-Wide Failures and Managed-Network Limits

When every device on the segment fails identically, stop working the endpoint. Log into the router settings and inspect the WAN DNS entries, any DNS filtering feature, and the firewall rules that might block outbound port 53.

On corporate or guest networks you often cannot change these. Document what resolves and hand it to whoever owns the network configuration, since local changes get overwritten by policy anyway.

Repair DNS Cache and Adapter Configuration

This is where the fix lands for most cases: clear the poisoned cache, put the DNS server addresses back to something known-good, and confirm the adapter bindings were not quietly changed by an installer or an old VPN client.

Flush the Local Resolver Cache on Windows, macOS, and Linux

Run these from an elevated command prompt or terminal:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Ubuntu / systemd Linux: sudo systemd-resolve --flush-caches (or resolvectl flush-caches on newer releases)

Chrome keeps its own cache too. Visit chrome://net-internals/#dns and clear the host cache, then chrome://net-internals/#sockets and flush socket pools. Skipping the browser-level flush is why a correct fix sometimes appears not to work.

Set DNS Back to DHCP or Use a Trusted Public DNS Server

Open the adapter properties, select Internet Protocol Version 4 (TCP/IPv4), and set DNS to obtain automatically. If the network’s own resolver is the failure, hardcode a public DNS server instead:

Provider	Primary	Secondary
Google DNS	8.8.8.8	8.8.4.4
Cloudflare	1.1.1.1	1.0.0.1

From the command line: netsh interface ip set dns name="Ethernet" static 8.8.8.8 then netsh interface ip add dns name="Ethernet" 8.8.4.4 index=2.

A DNS misconfiguration left behind by uninstalled security software shows up here constantly, usually as a loopback or 10.x address nothing answers on.

Check TCP/IPv4, Static Addressing, and Adapter Bindings

Look for a static IPv4 address that no longer matches the subnet, a stale secondary DNS entry, or IPv6 handing back an unreachable resolver while IPv4 looks correct.

Disable any leftover virtual adapters from VPN clients or hypervisors, and confirm the physical adapter sits above them in the binding order. Two adapters supplying conflicting DNS server addresses produce intermittent failures that survive every cache flush you throw at them.

Reset the Windows Network Stack Only When Needed

Treat this as the last configuration step, because it wipes custom routes, static entries, and Winsock LSPs:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns

Reboot afterward. Windows 11’s Network Reset under Settings > Network & Internet > Advanced does the same thing plus reinstalls network adapters, and it removes VPN clients, so document what needs reinstalling first.

Remove Software and Browser Interference

When the adapter is clean and public lookups resolve, something running on the endpoint is intercepting or rewriting DNS. VPN clients, proxy settings, and antivirus web-filtering modules are the usual culprits, in that order.

Clear Stale Browser Data and Test Without Extensions

Open Chrome’s clear browsing data dialog (Ctrl+Shift+Delete), select cached images, files, and cookies for all time, and clear. Delete temporary files while you are there.

Then launch an incognito window, which disables browser extensions by default. Resolution working in incognito and failing in a normal window narrows it to an extension, frequently an ad blocker or a security add-on with its own DNS-over-HTTPS setting. An outdated browser build is worth ruling out too: check chrome://settings/help and let any pending update install.

Disconnect VPN and Review Proxy Settings

Disconnect the VPN completely and retest. Many clients push their own resolvers and leave them behind after an ungraceful disconnect, so verify with ipconfig /all that the DNS entries reverted.

Check Windows Settings > Network & Internet > Proxy and clear any automatic configuration script or manual proxy server the reader did not deliberately set. Malware and old corporate images both leave proxy entries that silently break name resolution.

Check Firewall and Security Software DNS Controls

Temporarily disable third-party antivirus web protection and retest, then re-enable it. Windows Defender Firewall rarely blocks outbound 53, though custom rules from a previous admin do.

Suites with DNS filtering or “secure DNS” features redirect queries to their own resolvers. When the vendor’s resolver is unreachable, every lookup fails while the rest of the connection stays up. Whitelisting or turning off that single module usually restores service without removing the product.

Update Network Drivers When the Adapter Is Unstable

Open Device Manager, expand Network adapters, and check the driver date against the vendor’s current release. Pull the driver from the NIC or laptop manufacturer, since Windows Update often ships a generic build that drops connections under load.

Flapping links produce sporadic DNS failures that look like configuration problems. If the adapter logs disconnects in Event Viewer, fix the driver before spending more time on resolver settings, and review the broader network troubleshooting path for anything physical.

A Repeatable Path to Working DNS

The sequence holds regardless of platform: scope the failure with a DNS lookup against a second resolver, confirm the public DNS records look correct, restore connectivity, flush caches, then fix the network configuration on the adapter. Software interference comes last because it is the least common cause and the most disruptive to test.

Keep a note of what you changed on each endpoint. Static DNS entries and leftover VPN adapters are the two findings that repeat most across tickets, and both are trivial to spot once you know the order to check them in.

When the endpoint is clean and the problem persists across every device on the segment, the fault sits with the router configuration or the internet service provider’s DNS server, and that is a call to make rather than a setting to change. Run the domain through the PacketTools network tools before you make that call so you have propagation and record data in hand.

When a user says “the internet is down,” the fault is a name resolution problem more often than a routing problem. The Domain Name System sits between every application and the IP address it needs, so a single broken NS record, a stale cache entry, or a firewall dropping TCP port 53 can take down mail flow, VPN tunnels, and web apps at once while ping to 8.8.8.8 still works fine.

To troubleshoot DNS issues efficiently, work outward in layers: confirm the network path first, then the client cache and resolver config, then the specific records the affected service queries, and only then the authoritative nameservers and delegation. That order keeps you from flushing caches on twelve workstations when the real problem is a missing glue record at the registrar.

The tools at PacketTools were built for exactly this workflow, run from browser sessions during live incidents where a second opinion from outside your network settles an argument in about ten seconds. Nothing is logged, nothing needs a sign-in, and the output is plain enough to paste into a ticket.

How to Tell DNS From a Network Connectivity Fault

Split the fault domain in the first sixty seconds by testing an IP address directly. If ping 1.1.1.1 succeeds but ping cloudflare.com returns “could not find host,” you have a DNS failure, not a network connectivity fault. The error string your resolver returns, NXDOMAIN versus SERVFAIL versus a timeout, tells you which layer to open next.

Recognize Resolver Failures, NXDOMAIN, and SERVFAIL

NXDOMAIN means an authoritative server answered and told you the name does not exist. That points at a typo, a deleted record, or a search-domain suffix being appended to your query.

SERVFAIL means the resolver tried and could not complete the lookup. Common causes include DNSSEC validation failures, unreachable authoritative nameservers, and expired zone data on a secondary.

A timeout (“Request to server timed out” or “No response from server”) means the query never got an answer at all. Microsoft’s guidance on troubleshooting DNS servers notes this often means the DNS service is not running, or the server is not listening on the IP you queried.

Confirm Routing Before Changing DNS Settings

Run ipconfig /all on Windows or ip addr on Linux and verify the IP addresses, subnet mask, and default gateway are what you expect. A wrong subnet mask produces symptoms that look identical to DNS failure.

Then trace the path with tracert 1.1.1.1 on Windows or traceroute 1.1.1.1 on Linux. If the trace dies at hop two, stop touching resolver settings. A quick ping test from outside your network confirms whether the target is reachable at all.

Check IPv6 separately. Dual-stack hosts that get a broken IPv6 default route will hang on AAAA lookups before falling back to IPv4, which reads as “slow DNS” to users.

Compare Results Across Devices and Networks

Query the same name from three vantage points: the affected host, a second machine on the same VLAN, and a device on a cellular hotspot. One failing host means client config or cache. An entire VLAN failing means the resolver or a firewall rule. Everything failing everywhere means the zone itself.

Isolate the Resolver, Cache, or Client Configuration

Once routing checks out, the next three candidates are the configured DNS resolver, the local DNS cache, and the adapter’s IP configuration. A side-by-side query against your internal DNS server and a public DNS resolver separates the first from the other two in one command.

Query the Configured Resolver and Public DNS Side by Side

Run the same lookup against your resolver and a public one:

nslookup example.com 10.0.0.1
nslookup example.com 8.8.8.8
dig @1.1.1.1 example.com A

If 8.8.8.8, 1.1.1.1, or 9.9.9.9 answers correctly and your internal server does not, the problem is your resolver, its forwarders, or its recursion path. When both fail identically, move up to the authoritative layer.

Keep the secondary resolvers handy: Google Public DNS uses 8.8.8.8 and 8.8.4.4, Cloudflare uses 1.1.1.1 and 1.0.0.1. Testing both members of a pair catches a single dead primary DNS server.

Flush Stale or Corrupted Local DNS Cache Entries

DNS cache corruption produces the classic “works everywhere except this one laptop” symptom. Clear it by platform:

• Windows: ipconfig /flushdns, or Clear-DnsClientCache in PowerShell
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches or sudo resolvectl flush-caches
• Windows DNS Server role: dnscmd /clearcache or Clear-DnsServerCache

Inspect before you flush. ipconfig /displaydns shows what the client believes, and a wrong entry there is evidence worth capturing in the ticket.

Verify DHCP, Adapter Settings, and Resolver Order

Confirm which servers the client was handed. ipconfig /all on Windows lists the DNS servers per adapter; on Linux, read /etc/resolv.conf (or resolvectl status on systemd hosts).

Watch for a hard-coded public resolver on a domain-joined machine. That breaks internal name resolution while external lookups work perfectly, which is a maddening ticket to inherit. Resolver order matters too: Windows queries the first entry and only fails over after a timeout, so a dead primary adds seconds to every lookup.

Resolve-DnsName example.com -Server 10.0.0.1 -Type A gives cleaner structured output than nslookup for scripting these checks across a fleet.

Query the Records That the Affected Service Needs

Query the exact record type the broken service depends on, because a healthy A record tells you nothing about why mail is bouncing. Web traffic needs A, AAAA, and often CNAME records; mail needs MX plus TXT records for SPF; and the TTL in every answer tells you how long a bad value will linger.

Use nslookup and Dig to Test Specific Record Types

Set the query type explicitly:

nslookup -type=MX example.com 8.8.8.8
nslookup -type=TXT _dmarc.example.com
dig example.com MX +short
dig example.com TXT +short
dig www.example.com CNAME

For a full picture in one call, dig example.com ANY still works against some servers, though most modern resolvers refuse it. Query record types individually and you avoid the ambiguity.

Add +norecurse when you want to see only what a server holds in cache or authoritatively, with no upstream lookup.

Interpret Answers, Authority Data, and TTL Values

Read the dig header first. status: NOERROR with ANSWER: 0 means the name exists but has no record of that type, which is a different problem from NXDOMAIN.

The flags: line carries aa when the response is authoritative. No aa flag means you got a cached copy, and the TTL counting down in the answer section shows how much of the original lifetime remains.

A TTL of 3600 on a record you changed four minutes ago means resolvers will keep serving the old value for another 56 minutes. Lower TTLs to 300 before planned cutovers, not during them.

Check Website, Email, and IPv6 Records Separately

Test AAAA records independently of A records. A dual-stack client that gets a stale or wrong AAAA record will fail while every IPv4-only test passes.

For mail, verify the MX hostnames resolve to reachable IP addresses, then confirm the SPF record is a single TXT string starting with v=spf1. Two SPF records on one domain is a permanent error, and it is one of the most common findings when running an all-in-one check with the PacketTools SuperTool against a domain that “used to work.” Microsoft 365 tenants have their own record set worth checking with a dedicated M365 domain checker.

Trace Delegation and Authoritative DNS Failures

When every resolver you test returns SERVFAIL, the fault lives at the authoritative layer, and dig +trace walks the resolution path from the root servers down to the zone so you can see exactly which hop breaks. Broken delegations, missing glue records, and mismatched NS records between the registrar and the DNS provider all surface in that output.

Follow the Resolution Path With dig +trace

dig +trace example.com
dig +trace +additional example.com

The output shows each referral: root, then the TLD servers, then the nameservers your registrar has on file. A trace that stops at the TLD level with no referral means the parent zone has no delegation for your domain.

On Windows, replicate the same walk in nslookup with set norecursion and set querytype=NS, querying each server the previous level referred you to.

Validate NS Records, Glue, and Broken Delegations

Compare what the parent publishes against what the zone itself publishes:

dig @a.gtld-servers.net example.com NS
dig @ns1.example.com example.com NS

Any mismatch is a delegation defect. A “FAIL” on a delegation test typically indicates that the parent DNS zone does not contain a proper delegation record pointing at the child domain’s authoritative nameservers.

Glue records matter when nameservers live inside the zone they serve. Without an A record for ns1.example.com in the parent, resolution loops. Also confirm every NS record resolves to a reachable address, because one dead nameserver out of four produces intermittent failures that come and go by resolver.

Separate DNS Propagation Delays From Incorrect Zone Data

Propagation is TTL expiry, not a mysterious internet-wide sync. If the authoritative server already returns the new value and a public resolver returns the old one, wait out the TTL. If the authoritative server returns the old value, the zone edit never saved.

Check both at once with a DNS propagation checker that queries resolvers in multiple regions. Consistent old answers everywhere plus a correct authoritative answer confirms caching; scattered results point at a nameserver out of sync with its peers. Comparing SOA serials across all authoritative servers settles that question definitively.

Repair Server-Side and Transport-Layer Problems

Server-side DNS problems cluster around three things: blocked port 53 traffic, a stopped or misbound DNS service, and zone data that never transferred. Firewall rules that permit UDP but drop TCP break large responses and zone transfers while small lookups keep working, which makes the failure look intermittent.

Allow DNS Traffic on UDP and TCP Port 53

Open both. UDP port 53 carries standard queries; TCP port 53 handles responses too large for a single UDP datagram and all zone transfers.

Test each transport separately:

dig @10.0.0.1 example.com A
dig @10.0.0.1 example.com A +tcp

If the UDP query works and the TCP one hangs, you found the rule. Microsoft’s server guidance points at exactly this scenario, noting that an intermediate packet-filtering router or proxy can force a DNS server onto a non-standard port and break nslookup, which sends to UDP 53 by default.

Also confirm nothing upstream is intercepting and rewriting DNS, a common ISP behavior that silently answers NXDOMAIN queries with a search page.

Check Windows Server and BIND Service Health

On Windows Server, start with the Application, System, and DNS Server event logs. A “Server failure” or “Query refused” response to an nslookup usually means the zone is paused, which shows on the General tab of the zone properties in the DNS console.

Restart the service with net start DNS when nslookup reports a timeout. Then check the Interfaces tab: an administrator can restrict the server to selected addresses, and querying an address outside that list fails silently.

For BIND, run named-checkconf and named-checkzone example.com /var/named/example.com.zone before reloading, then watch /var/log/messages or the journal for load errors.

Correct Zone Transfers, Forwarding, and Hosts File Overrides

Compare serial numbers between primary and secondary. When the primary’s serial is less than or equal to the secondary’s, the transfer will never fire; bump the primary and force a refresh with dnscmd /zonerefresh corp.contoso.com.

Check the Forwarders tab in the DNS console. A forwarder pointing at a decommissioned resolver produces timeouts on every external name while internal lookups succeed.

Then check the hosts file. C:WindowsSystem32driversetchosts or /etc/hosts overrides DNS entirely, and a leftover line from a migration test is a real root cause you will find more than once.

Make DNS Failures Faster to Diagnose Next Time

Work the layers in order and most DNS troubleshooting collapses into a few commands: confirm the path with ping and traceroute, split client from resolver by querying 8.8.8.8 or 1.1.1.1 alongside your internal server, pull the specific record type the broken service needs, then walk dig +trace down to the authoritative nameservers when everything else checks out.

Keep the evidence. A dig header showing status: SERVFAIL, a TTL still counting down on a record you changed, or a serial mismatch between primary and secondary turns a vague ticket into a fix.

DNS monitoring closes the loop by catching zone changes and nameserver drift before users call. Between incidents, the PacketTools DNS lookup and network tools give you an outside-the-firewall view of what the rest of the internet sees, and the broader network troubleshooting material covers the latency, TLS, and email-deliverability paths that DNS resolution feeds into.