DNS_PROBE_FINISHED_NXDOMAIN: Fix It Safely

DNS_PROBE_FINISHED_NXDOMAIN means that the DNS resolver your device reached returned an NXDOMAIN (name does not exist) answer for the hostname you requested. Your browser therefore has no address to connect to. It does not, by itself, prove that the web server is down or that the domain is gone for everyone.

What DNS_PROBE_FINISHED_NXDOMAIN means

DNS is the naming system that maps a hostname such as www.example.com to records such as an IPv4 address, IPv6 address, or alias. In the DNS protocol, NXDOMAIN is response code 3, called “Name Error.” RFC 8020 explains that a resolver treats a nonexistent name as having no names underneath it either.

It describes the DNS view that answered you. A typo, expired domain, wrong nameserver, stale negative cache, hosts-file entry, or split DNS can make one resolver say a name does not exist. An existing name without the requested A or AAAA normally returns NOERROR with no matching data (NODATA), not NXDOMAIN.

Find the broken DNS layer before changing settings

Use the scope of the failure to choose the smallest useful test. Try the same full URL in another browser, on another device, and on a phone using cellular data rather than Wi-Fi. The pattern is more informative than repeatedly refreshing one tab.

Run nslookup <hostname> on Windows or dig <hostname> on macOS and Linux, then repeat against another resolver with nslookup <hostname> <resolver-address> or dig <hostname> @<resolver-address>. Only the default resolver returning NXDOMAIN points local or upstream; agreement between independent resolvers points to the domain side.

Fix the local device

Make one change, test the same hostname, and record the result. The local cache steps are also covered in Loqmi’s DNS cache guide.

Windows 11

Open Settings > Network & internet, choose Wi-Fi or Ethernet, and use IP assignment > Edit > Manual to inspect DNS. Microsoft documents those fields and DNS over HTTPS in its Windows network settings guide. In an elevated Command Prompt, run ipconfig /flushdns and test with nslookup <hostname>. Leave Network reset for last: Settings > Network & internet > Advanced network settings > Network reset removes adapters and can affect VPNs.

macOS

Open Apple menu > System Settings > Network, select the active service, then choose Details > DNS. Record existing values before testing a replacement. In Terminal, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder clears common local caches and dig <hostname> tests the result. The current path is described in Apple’s Mac DNS guide.

Linux

Linux has no single DNS menu. In GNOME, open Settings > Network, select the connection’s gear button, then inspect IPv4 > DNS or IPv6 > DNS. With systemd-resolved, use resolvectl status, resolvectl query <hostname>, and sudo resolvectl flush-caches. If unavailable, check NetworkManager or /etc/resolv.conf; direct edits may be overwritten.

Android

On stock Pixel-style Android, open Settings > Network & internet > Private DNS. Return a custom provider to Automatic, tap Save, and test again; other manufacturers may rename menus. To compare Wi-Fi and cellular, open Settings > Network & internet > Internet, turn Wi-Fi off, and retry. Chrome has its own path: Chrome > Settings > Privacy and security > Use Secure DNS.

iPhone and iPad

For the connected Wi-Fi network, open Settings > Wi-Fi, tap the Info button, then Configure DNS. Set it to Automatic for a comparison; Manual applies only to that Wi-Fi network. If it still fails, try cellular data. As a last resort, Settings > General > Transfer or Reset [device] > Reset > Reset Network Settings removes saved Wi-Fi, VPN, and network settings.

When every network returns NXDOMAIN

If the same hostname fails on unrelated networks and independent resolvers, the visitor cannot repair it locally. A domain owner should confirm that the registration is active, the registrar delegates the domain to the intended nameservers, and the record exists in that authoritative zone. Query the exact nameserver with dig @<authoritative-nameserver> <hostname> A, or use dig +trace <hostname> to see where the referral chain stops.

Check the apex and important subdomains separately. A missing www CNAME is not fixed by adding an A record to the apex, and a record created at a non-authoritative provider has no effect. A new name can remain negatively cached until its TTL expires; DNS TTL explains why there is no universal propagation timer. See RFC 2308 for negative caching.

Avoid common false fixes

Changing DNS servers can help when your current resolver is stale, unreachable, or applying a policy to the name. It cannot create an authoritative record, renew a domain, or guarantee faster internet. Note the original values and follow Loqmi’s DNS-server change guide so you can restore them.

DNS over HTTPS, browser Secure DNS, Android Private DNS, and VPN DNS are different resolver paths. They can make two apps see different answers. Encryption protects the DNS connection to the selected resolver; it does not hide the query from that resolver or replace HTTPS.

A quick self-test with Loqmi

1. Open Loqmi’s IP tool and note the public IP, ISP, and approximate location. DNS normally does not change the public IP shown.
2. Run nslookup loqmi.com or dig loqmi.com. Note the answering resolver and whether an address is returned. This tests your DNS path, not the failing hostname.
3. Repeat the lookup for the exact failing hostname on Wi-Fi and another network. If Loqmi resolves in both places but the target returns NXDOMAIN, focus on the target’s records or delegation.
4. Use Loqmi’s speed test only to compare latency and throughput before and after a DNS change. It cannot prove DNS health or repair NXDOMAIN.

Once the name resolves, a remaining failure belongs to a later layer such as TLS, the web server, a firewall, or the application. DNS troubleshooting is finished when the lookup is correct, not merely when a browser happens to reload.