DNS translates names into network addresses. Enter a hostname only—without a path—to check whether the LumaProbe server can retrieve public A or AAAA records.
A successful result confirms public resolution from this server, not every resolver worldwide. A failure may be temporary, local to a DNS provider, or caused by a misspelled or unpublished domain.
The checker validates a public domain name, then asks the LumaProbe server resolver for its A and AAAA records. It reports up to eight distinct IPv4 or IPv6 addresses and the time taken by that server-side lookup. It does not query private names or display every DNS record type.
Because resolution happens on the server, the test answers “does this name resolve from LumaProbe’s resolver?” It does not directly test the DNS cache in your browser, device, router or provider. That distinction makes comparison with your affected device important.
Use one device and one browser for comparisons. Pause cloud backups, game downloads, streaming and large file transfers, then note whether the device is connected by Wi-Fi, Ethernet, mobile data or a VPN. Run the check at least three times instead of choosing a single unusually good or bad result.
Change only one condition at a time. For a Wi-Fi problem, compare beside the router with the affected room. For a suspected broadband fault, add an Ethernet result if practical. Record the time because congestion and provider work can make the same connection behave differently during the day.
A returned address confirms that public address records were available to the server at that moment. Different resolvers can return different addresses because of caching, geographic routing, load balancing or a record change. A failed lookup may reflect an invalid name, missing records, propagation or a temporary resolver problem.
If LumaProbe resolves a name while one device does not, focus on that device’s cache, configured resolver, VPN, filtering or router. If multiple independent resolvers fail, the domain owner or authoritative DNS configuration may be involved.
A browser sees the complete path from this device to LumaProbe, including the device, local network, provider route and test server. It cannot isolate the broadband line on its own. Browser scheduling, security software, VPNs, extensions and background activity can also influence a short test.
Treat the result as diagnostic evidence, not a contractual line measurement or a live provider-outage declaration. A provider can test a different network boundary and report a different valid number. The most useful conclusion usually comes from controlled comparisons and repeated observations.
Check the spelling and try a known working domain. Restarting the browser or device can clear some transient state; operating systems also provide documented DNS-cache commands. Avoid copying unknown resolver addresses from forums.
A reputable public resolver can be used as a controlled comparison, but changing DNS affects privacy and filtering. Save the original automatic settings so they can be restored. Domain owners should inspect authoritative records and DNSSEC with specialist tools.
Read the complete LumaProbe test methodology and privacy notes →
No browser test is exact. Device performance, browser limits, server distance and other network traffic affect the result. Compare repeated tests under the same conditions.
Test results are stored only in your browser when local storage is available. The public application does not create a user account or central result profile.
Repeat the test, pause other traffic and compare Wi-Fi with Ethernet. Change one condition at a time so the cause becomes clearer.