LumaProbe

DNS problems explained and safely troubleshot

Understand resolvers, caches, records and propagation, then distinguish a DNS fault from a wider connection or website problem.

Independent guidance
Start with the free diagnostic steps. Affiliate links appear only where a product category could address the problem identified in this guide.

Key takeaways

  • DNS translates names into records; a working internet path can still appear broken when resolution fails.
  • A server-side DNS checker does not directly test the resolver cache on your device or router.
  • Changing resolver is a controlled diagnostic choice with privacy and filtering consequences.

What happens when you enter a name

A device usually asks a recursive resolver for information about a domain. The resolver may answer from cache or follow the DNS hierarchy to authoritative name servers. An A record provides an IPv4 address and an AAAA record provides an IPv6 address. Other record types describe mail, aliases, service policy and delegation.

DNS is distributed and cached. Time to Live values tell caches how long an answer may be retained. Consequently, two users can temporarily receive different valid answers during a planned change, and a failure in one resolver does not prove that every resolver or the website itself is down.

Recognise a likely DNS symptom

A DNS fault often produces a name-resolution error while direct network connectivity still works. One site can fail because its records or authoritative servers are wrong; many unrelated names can fail because the device, router or configured resolver is affected. A website can also return an HTTP error after DNS succeeds, which is a different stage.

Try two familiar sites and check the exact error. Do not use a random IP address as a universal website test: HTTPS certificates and virtual hosting depend on the hostname, and large services can use many changing addresses.

Understand the LumaProbe result

The LumaProbe DNS tool asks its server-side resolver for public A and AAAA records and reports the addresses and lookup time. This can confirm that the name resolves from that server. It does not directly query the cache used by the visitor’s browser, operating system, router or provider.

If LumaProbe succeeds while the affected device fails, check that device’s DNS setting, VPN, filtering application, browser secure-DNS option and cache. If multiple independent public resolvers and authoritative checks fail, the domain’s DNS configuration becomes a stronger suspect.

Clear transient state carefully

Check spelling first. Restart the browser, then the affected device. A router restart can clear some forwarding state, but repeated factory resets are unnecessary and can remove provider configuration. Operating systems offer documented cache-flush commands; use the vendor’s current instructions rather than copying an unknown command with administrator privileges.

Reconnect to the network and compare another device. If only one browser fails, extensions, security software or its secure-DNS setting may be involved. Preserve parental-control and workplace policies rather than bypassing them without permission.

Compare another resolver responsibly

A reputable public recursive resolver can be used temporarily to compare with the provider’s automatic setting. Record the original configuration so it can be restored. A change may affect content filtering, local service names, privacy, geographic routing and support, so it is not automatically “faster” or better for every household.

Encrypted DNS protects a query between the client and compatible resolver, but it does not make a false DNS record true and does not hide the destination from every part of the connection. For a managed work device, use only employer-approved settings.

For domain owners

Check delegation at the parent, authoritative name-server availability, record values, DNSSEC validation and certificate configuration. Raise the SOA serial when operating a traditional zone that requires it and plan changes around TTLs. A dashboard showing the desired record does not prove that the public delegation reaches it.

Use authoritative diagnostics and monitoring from more than one network. Avoid “flushing global DNS” claims: there is no single global cache. Correct the authoritative data, wait for legitimate cached entries to expire and communicate the expected change window.

Recommended next checks

Compare results beside the router, in the problem location and over Ethernet where possible. Repeat under the same conditions rather than relying on one run. LumaProbe’s browser measurements describe the complete path to its server, so use them to narrow the fault—not as a substitute for a provider line diagnostic.

Sources and further reading

External guidance can change. Sources and links were checked on 19 July 2026.

More help

Browse all internet and Wi-Fi guides, read how LumaProbe tests connections, or report a correction through LumaContact.