Whether the expected records exist
Check A, AAAA, CNAME, and NS records. Missing, stale, or wrong record types can break access before an HTTP request starts.
Online DNS tool and troubleshooting guide
Online DNS lookup and multi-location DNS checker
Enter a domain to query A, AAAA, CNAME, or NS records from 13CE probes in Vietnam. Optionally choose a public or ISP resolver to separate authoritative-record problems from cache and resolver behavior.
- Vietnam multi-location checks
- A / AAAA / CNAME / NS lookup
- Optional custom DNS resolver
Run a DNS check now
This uses the existing 13CE test service and opens the same unified result page used by the homepage.
No second result system is involved: this form reuses /api/dnsjob and the unified result page.
What can a multi-location DNS check confirm?
A single lookup shows one resolver’s current answer. Comparing probes helps expose geographic steering, stale caches, and incomplete changes.
Whether answers differ by location
Different IPs are not automatically an error: CDNs and GeoDNS often steer users intentionally. The question is whether the difference matches your design.
Whether the resolver changes the answer
Retest with a public, ISP, or enterprise resolver to separate authoritative configuration from recursive cache, policy, or ECS behavior.
How to use the DNS lookup tool
1
Enter a hostname
Use a bare domain or hostname such as example.com or www.example.com. If you paste a full URL, the form extracts its hostname.
2
Choose the record type
A is IPv4, AAAA is IPv6, CNAME exposes an alias entry, and NS lists authoritative name servers.
3
Optionally choose a resolver
Leave it blank to use each probe’s system resolver, or enter an address such as 8.8.8.8 or 1.1.1.1 for a controlled comparison.
4
Compare the result page
Look for missing or different answers, then run HTTP or latency tests to verify whether those differences affect users.
How to interpret DNS results
| Observed result | Likely explanation | Recommended next step |
|---|---|---|
| All probes return the same record | The change has propagated, or the service does not use geographic steering | Run an HTTP check against the hostname to confirm that the returned destination responds correctly. |
| A few probes still return an old IP | Recursive cache has not expired, TTL is long, or authoritative servers are inconsistent | Verify authoritative records and change time, then repeat the same probe comparison after the TTL window. |
| Regions return different IPs | CDN, GeoDNS, ISP policy, or an unintended steering rule | Confirm whether the split is designed; test HTTP status and latency for each destination. |
| A selected resolver changes the answer | Resolver cache, ECS, filtering, or local policy differs | Compare system and selected resolvers side by side and query the authoritative NS as the baseline. |
| AAAA exists but IPv6 access fails | DNS is published while the origin, firewall, or route is not ready for IPv6 | Validate the IPv6 TCP and HTTP path before removing or keeping the AAAA record. |
Four common troubleshooting scenarios
Propagation after a DNS change
After switching origin or CDN, track where old and new answers appear instead of trusting one local cache.
A site fails only in some locations
Check whether failing locations resolve to a different IP, then test that destination over HTTP and TCP.
Public and ISP resolvers disagree
Retest with explicit resolvers. If authoritative data is correct, cache expiry or resolver policy is the likely next investigation.
IPv4 works but IPv6 fails
Compare A and AAAA, then verify listening ports, certificates, firewall rules, and routing on the IPv6 destination.
Example: two A-record groups for one hostname
Suppose most Vietnam probes return 203.0.113.10, while a few still return 198.51.100.20.
Difference alone does not prove failure. First confirm whether CDN or GeoDNS steering is expected. If it is not, inspect authoritative records, TTL, and change timing. Then run HTTP checks for the hostname and verify whether both destinations serve the correct response.
What this tool does not prove
A DNS answer does not by itself prove website availability. Confirm authoritative configuration separately, and combine DNS results with HTTP status, TCP reachability, and latency before deciding on a fix.
DNS lookup questions
What is the difference between DNS lookup, DNS check, and DNS resolution?
They often describe the same search intent. Resolution is the process of turning a name into records, lookup is the query itself, and a DNS check adds comparison and diagnosis.
Why does a domain resolve locally but fail elsewhere?
Possible causes include incomplete authoritative updates, recursive cache, delegation or DNSSEC errors, and network-specific resolver behavior. Compare multiple probes and query authoritative servers.
Do multiple returned IPs mean the DNS is wrong?
Not necessarily. Load balancing, CDNs, and GeoDNS commonly return multiple or location-specific IPs. It becomes a problem when an answer is unintended or a destination cannot serve the site.
How long does a DNS change take to propagate?
It depends on the previous TTL, recursive cache behavior, and authoritative consistency. TTL is a guide, but real refresh time varies by resolver, so repeat checks during the change window.
Can I test 8.8.8.8 or 1.1.1.1?
Yes. Enter the resolver IP in the optional field. Leave it blank to use each probe’s system resolver and observe the local network path.
Authoritative references
Use the protocol standards and resolver documentation when you need to verify DNS behavior beyond one test result.
DNS differs—what should you test next?
Compare resolver behavior, then verify HTTP availability and latency for the destinations returned.