Fix DNS server not responding and NXDOMAIN

Fix DNS server not responding by isolating where resolution breaks: device cache, router, ISP resolver, authoritative DNS, or a missing record. NXDOMAIN means the queried name does not exist in DNS as seen by that resolver, so treat it as a record, spelling, or delegation problem.

Start with the error, not the browser

The browser is usually only the messenger. DNS server not responding means your device asked a resolver for an answer and did not get a usable reply. That resolver may be your router, ISP, public DNS service, or corporate VPN.

NXDOMAIN is a different failure. The resolver answered, but the answer says the name does not exist. In practice, that points to a typo, deleted record, not-yet-delegated domain, or hostname that only exists inside a private network.

Separate those cases before you start clicking through settings. Restarting a router can clear a silent resolver. It will not create a missing DNS record, repair wrong nameservers, or publish a forgotten subdomain.

Quick diagnosis matrix

This table is the shortcut most generic help pages skip. A DNS fix that ignores the layer can hide the real fault and make the next outage harder to debug.

Local device checks

Start on the device where the error appears. Clear the DNS cache, reconnect the active network, and disable any VPN or security filter just long enough to prove whether it is intercepting DNS. Do not leave protection disabled; this is a test, not a new operating model.

On Windows and macOS, the goal is boring and useful: force the device to forget stale resolver answers and ask again through a clean network path. On phones, toggling Wi-Fi and mobile data often separates device cache from network failure.

If only one browser fails, check its DNS-over-HTTPS setting before blaming the router. A browser can take its own resolver path while the operating system uses another one.

Router, ISP, and public resolver checks

If every device on the same Wi-Fi fails, move upstream. Reboot the router, check whether the network has a captive portal, and test with a trusted public resolver. This is a diagnostic comparison, not a universal order to abandon your ISP.

Public resolvers can be faster or steadier in some markets, but they also change privacy, filtering, and support expectations. In the United States, United Kingdom, and Canada, readers often compare ISP DNS with public resolvers because the same query crosses home, office, and mobile networks.

For businesses, resolver choice is also a policy question. If your company uses split-horizon DNS, a public resolver may fail for internal hostnames that only exist on the corporate network.

NXDOMAIN means look at the zone

NXDOMAIN is not a timeout. It is a negative answer. For your own domain, inspect the exact hostname, the zone where the record should live, and the nameservers currently delegated at the registrar.

The common trap is editing DNS in the wrong panel. A domain registered at one company can use nameservers from another provider. Your registrar, CDN, web host, and email host may all show DNS controls, but only the authoritative nameservers answer public queries.

HostScout tracks domain, CDN, and email providers as separate buying surfaces because DNS mistakes often cross those boundaries. A domain can sit at Porkbun or Namecheap, proxy web traffic through Cloudflare, and route mail through a separate email provider.

Hosted domains: what to check before changing providers

Do not move a domain just because a DNS error appears. First confirm whether the current provider is actually authoritative for the failing name. Provider switching is a last resort, not a troubleshooting step.

Check these areas before you touch billing or transfer settings:

• Nameserver delegation: the registrar should point to the provider that actually hosts the zone.
• Record ownership: the hostname should exist in the authoritative zone, not only in a staging panel.
• CDN proxying: a proxied record can hide the origin address and change failure symptoms.
• Email dependencies: mail records should survive website DNS changes unless you deliberately migrate email.
• Domain status: expired, suspended, or locked domains can look like DNS faults from the outside.

For comparison work, use HostScout’s domain provider, CDN, and email hosting views as separate checks. That keeps a resolver failure from turning into an unnecessary hosting migration.

When to change DNS settings

Change local DNS settings when the same website works through another network or another resolver. That points to a resolver-path problem. Keep a note of the old settings so you can reverse the change if corporate access, parental controls, or local filtering breaks.

Change authoritative DNS when you own the domain and NXDOMAIN appears for a hostname that should exist publicly. In that case, the fix is a correct record in the correct zone, plus patience for cached answers to age out.

Avoid changing both at once. One change per test is slower, but it tells you which layer actually fixed the problem.

Method and freshness

This article uses common English-language search questions from New York, London, and Toronto to separate general resolver troubleshooting from provider and domain ownership checks. Public provider examples come from HostScout’s current domain, CDN, and email coverage, not from competitor articles.

The article avoids volatile prices, rankings, review counts, and SLA claims because they do not help fix a DNS outage. Those values belong in provider comparisons where they can be refreshed and mapped directly to source data.