What DNS_PROBE_FINISHED_NXDOMAIN means
Chrome shows DNS_PROBE_FINISHED_NXDOMAIN when it asked DNS for the address of a website, got no address back, and then ran a quick check that showed your DNS resolver itself is working. So the problem is the name, not your internet connection. In DNS terms, NXDOMAIN is response code 3, "name error": the authoritative servers for the domain say the name does not exist. Under RFC 8020, a name that does not exist also means nothing underneath it exists, so if example.in is NXDOMAIN, www.example.in is too.
Chrome shows the same page when the name exists but has no address record for it, which DNS reports as a reply with no answer rather than as NXDOMAIN. Either way, the browser has no IP address to connect to.
Quick-fix checklist
- Check the spelling, including the ending:
.in,.co.inand.comare different domains. - Try the site on mobile data instead of Wi-Fi. If it loads there, the fault is on your network or device.
- Clear Chrome's cache: open
chrome://net-internals/#dnsand click Clear host cache. - Flush the operating system's DNS cache (commands below).
- Switch off any VPN, proxy or filtering app and try again.
- Try a public resolver such as 1.1.1.1 or 8.8.8.8.
- If you own the site, check the domain's expiry date, status and nameservers with
whoisanddigbefore changing anything else.
Visitor side vs site owner side
The quickest way to tell whose problem it is: look the name up from somewhere other than your own network.
| What you see | Likely side | Where to look |
|---|---|---|
| Site fails on your Wi-Fi, works on mobile data | Visitor | Local cache, router DNS, VPN, filtering |
Fails everywhere, dig shows status: NXDOMAIN | Owner | Expiry, domain status, nameservers |
Fails everywhere, status: NOERROR but no answer | Owner | Missing A, AAAA or CNAME record |
Fails everywhere, status: SERVFAIL | Owner | DNSSEC or broken nameservers |
Fixes on the visitor side
Typos and stale cache
A mistyped domain is the most common cause and the only one where NXDOMAIN is the correct answer. If the address is right, the next suspect is a cached negative answer. Resolvers remember an NXDOMAIN for a time set by the domain's SOA record (RFC 2308 uses the lower of the SOA's own TTL and its MINIMUM field), so a site that was broken an hour ago can still look broken after the owner has fixed it.
Flush DNS on Windows, macOS and Chrome
On Windows, open Command Prompt and run:
ipconfig /flushdnsMicrosoft's documentation notes that this discards negative entries as well as normal ones, which is exactly what you want here.
On macOS, open Terminal and run:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderIn Chrome, Edge or another Chromium browser, go to chrome://net-internals/#dns and click Clear host cache. Then close and reopen the tab.
Change the resolver
Your ISP's resolver may be slow to pick up changes, or may answer NXDOMAIN on purpose for names it blocks. Setting 1.1.1.1 or 8.8.8.8 on the device or the router rules that out. (Quad9 at 9.9.9.9 deliberately blocks known malicious domains, so it is not the best choice for this test.) Which of these is fastest from your connection is measured in the fastest DNS resolvers for India. Check also whether Chrome's Use secure DNS setting (Settings, Privacy and security, Security) points at a provider that filters.
VPN, proxy and hosts file
A VPN or corporate network usually sends lookups to its own resolver, which may not see public names or may filter them. Disconnect and retest. The hosts file overrides DNS for any name listed in it; it lives at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on macOS and Linux. Remove any leftover line for the domain, especially after a site migration where you tested the new server that way.
Causes on the site owner side
The domain has expired or been suspended
When a domain is not renewed, or the registrar or registry suspends it, it is often given the EPP status clientHold (set by the registrar) or serverHold (set by the registry). ICANN explains that either status means the domain is not activated in the DNS: the registry stops publishing the delegation and the whole domain disappears. (Some registrars instead point an expired domain at a parking page, in which case it resolves but shows the wrong site.) Check it with:
whois example.in | grep -iE "expir|status|name server"On Windows without whois, use your registrar's or the registry's web lookup. If you see an expiry date in the past or a hold status, renew or resolve it at the registrar; nothing on the hosting side can fix this. Unverified registrant contact details are another common reason for a hold.
Nameservers are wrong or were just changed
The registrar tells the registry which nameservers answer for your domain. If those servers do not have a zone for it, or the names are misspelt, lookups fail. Compare the nameservers DNS actually returns with what you expect:
dig NS example.in +short
dig +trace example.inThe first command shows the nameservers your resolver currently sees. +trace follows the delegation from the root through the registry's servers, so you can see what the registry delegates to and exactly where the lookup stops. After a nameserver change, allow for caching: the old delegation can live on for the TTL the registry publishes, and an NXDOMAIN cached during the gap lingers for its negative TTL. Never point nameservers at a provider before the zone exists there.
The record for that name is missing
The domain can be fine while one name is not. A common case is example.in working but www.example.in failing because nobody created the www record. Each hostname you want to reach needs an A record (IPv4), an AAAA record (IPv6), or a CNAME to another name. A CNAME cannot sit on the root of the domain. Query the authoritative server directly to bypass caches:
dig www.example.in A @ns1.yourdnsprovider.com
dig www.example.in AAAA @ns1.yourdnsprovider.comDNSSEC is broken: SERVFAIL, not NXDOMAIN
If DNSSEC is switched on at the registrar but the signatures or DS record no longer match the zone, validating resolvers refuse the answer. RFC 4035 requires them to return SERVFAIL (response code 2), not NXDOMAIN. This usually happens after moving to new nameservers while the old DS record is still at the registrar. Test with and without validation:
dig example.in A @1.1.1.1
dig example.in A @1.1.1.1 +cdIf the first returns SERVFAIL and the second, which skips validation, returns an address, DNSSEC is the problem. Remove or update the DS record at the registrar. A true NXDOMAIN means the name really is missing; SERVFAIL means the resolver could not get a trustworthy answer.
How to read dig and nslookup output
With dig, the line to read is the header:
dig example.in A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41522status: NXDOMAIN– the name does not exist in DNS.status: NOERRORwith an empty ANSWER section – the name exists but has no record of that type.status: SERVFAIL– the resolver could not get a valid answer, often DNSSEC or unreachable nameservers.
On Windows, nslookup example.in 8.8.8.8 reports an NXDOMAIN as "Non-existent domain". Comparing two resolvers, for example your ISP's and 8.8.8.8, shows quickly whether the fault is local.
How this applies on Bigdomainhost
Bigdomainhost does not sell or register domains. Your domain stays with your registrar, and that is where you renew it, clear any hold status and set nameservers or DNSSEC. Hosting only needs the right records to point at your server.
- You can point the domain at
ns1.bigdomainhost.comandns2.bigdomainhost.com; domains on our nameservers get full DNS management at no charge, edited in the client area. The record types and nameserver details are in the DNS documentation. - On Web & cPanel hosting, the cPanel DNS zone editor is unlocked, so you can add a missing
wwwor subdomain record yourself. - A KVM VPS comes with a dedicated IPv4 address and an IPv6 /64; create an A record for the IPv4 address and, if you serve over IPv6, an AAAA record too.
- If you are moving from another host, lower the TTL first and follow the migration checklist; our team moves sites and DNS records free of charge.
If a domain hosted with us shows this error and you cannot see why, send the domain name and your dig output to support on +91 75994 50220 (phone or WhatsApp, 24x7) or support@bigdomainhost.com.