You want to know which public recursive resolver answered the DNS query shown on the page.
Resolver Information Check
Inspect recursive resolver context for a live DNS query.
Use Resolver Information Check to query a hostname through a public recursive resolver, review the returned DNS status and records, and understand more clearly whether the answer may be tied to resolver behavior rather than authoritative DNS alone.
Check the recursive resolver context before assuming the DNS zone itself is wrong.
Resolver result
example.com
READY
Type Value TTL
Check Result Time
No records were returned for this hostname and record type through the current recursive resolver.
What this Resolver Information Check tool does
Resolver Information Check queries a hostname through the public recursive resolver used by this page and shows the returned status, answer records, and resolver-side response context.
Use it when you need more clarity on what the recursive layer is returning before moving to propagation, nameserver, or DNSSEC checks.
It does not expose every internal resolver hop. It focuses on the practical recursive answer visible to this page.
When to use this tool
A DNS answer looks unexpected and you need to confirm whether the issue is tied to the resolver path rather than the zone data itself.
You are comparing public resolver behavior and want a quick first look at answer source, status, and returned records.
A cached response looks stale and you want more resolver context before moving to propagation checks.
You need to confirm whether a recursive resolver is returning NOERROR, NXDOMAIN, SERVFAIL, or an empty answer set for the hostname.
You want a focused resolver-context check before digging into nameservers, propagation, or encrypted DNS endpoints.
How to use Resolver Information Check
- Enter the domain or hostname you want to inspect.
- Select the record type you want to query.
- Run the check and review the returned DNS status and answer set.
- Use the resolver observations to understand the recursive response context.
- If the answer looks wrong or incomplete, continue to propagation, nameserver, or DNSSEC checks.
How to interpret resolver results
Resolver answered normally
Likely meaning: A public recursive resolver returned a usable DNS status and record set for the hostname.
Common causes: This usually means the resolver path used by the page can complete the query successfully.
Next action: Compare the returned records with your expected DNS state, then continue to propagation or nameserver checks if needed.
Empty answer set
Likely meaning: The resolver answered the query, but no records were returned for the selected type.
Common causes: The hostname may exist without that record type, the record may be missing, or the query type may be wrong.
Next action: Try another record type and compare with DNS Lookup or the broader zone configuration.
NXDOMAIN
Likely meaning: The resolver reported that the queried hostname does not exist.
Common causes: Typos, missing subdomains, wrong hostnames, or unpublished records are common causes.
Next action: Verify the exact hostname, then compare with nameserver and propagation checks.
SERVFAIL
Likely meaning: The resolver could not complete the query cleanly.
Common causes: DNSSEC, delegation, upstream authority problems, or resolver-side issues can cause this.
Next action: Run DNSSEC Check and NS Lookup next, then compare with other resolver views.
Resolver context matters
Likely meaning: The returned answer depends on the recursive resolver path used for the query.
Common causes: Resolver cache state, timing, policy, and upstream refresh behavior can all change what you see.
Next action: Use this as resolver context, then compare with DNS Propagation Check or a different resolver path.
Common issues this tool helps uncover
A public recursive resolver returns a stale-looking answer
The hostname exists, but the selected record type returns no data
Different recursive resolvers return different answers or statuses
Resolver-side failure is mistaken for an authoritative DNS problem
The query is correct, but the answer source is not the resolver the user expected
DNSSEC or delegation issues surface as recursive resolver failure first
Next steps after Resolver Information Check
Open DNS Lookup
Use the broader DNS lookup page to inspect multiple record types for the same hostname.
Check propagation
If the answer looks stale or inconsistent, compare multiple public recursive resolvers.
Check DNSSEC
If the resolver returns SERVFAIL, inspect DNSSEC before assuming it is only a cache issue.
Verify nameservers
If the recursive answer looks wrong, confirm which provider is authoritative for the hostname.
Related tools
DNS Lookup
Query A, AAAA, CNAME, TXT, and other DNS records for a domain.
DNS Propagation Check
Verify whether recent DNS changes are visible across resolvers.
DoH Endpoint Check
Test a DNS-over-HTTPS endpoint with a live JSON query and inspect the response.
NS Lookup
Check authoritative name servers and delegation for a domain.
DNSSEC Check
Validate whether a domain has DNSSEC configured correctly.
Resolver Information Check FAQ
What does Resolver Information Check show?
It shows the DNS status, returned records, and resolver-side context for a query made through the public recursive resolver used by this page.
Does this identify every resolver hop?
No. It focuses on the public recursive resolver response visible to this page, not the full network path behind it.
What input should I enter?
Enter a domain or hostname such as example.com, www.example.com, or mail.example.com, then choose the record type you want to inspect.
Why would this page help if I already have DNS Lookup?
It puts more emphasis on the recursive resolver response context so you can understand whether the answer may be resolver-specific.
What should I check next if the answer looks wrong?
Usually DNS Propagation Check, DNSSEC Check, NS Lookup, and then broader DNS Lookup on the same hostname.