Check whether a DNS change has reached common recursive resolvers
Compare Cloudflare, Google, and Quad9 answers side by side without treating any one cached resolver view as the authoritative zone.
DNS Checker
Free, no signup. Ask three public resolvers the same DNS question. When their answers differ, you can see the propagation evidence instead of guessing.
For PTR, enter either a reverse DNS name or an IPv4 address. Each resolver is queried independently.
Checks run from our server; we fetch the URL you enter and don't keep the results. Queries use Cloudflare, Google, and Quad9 DNS-over-HTTPS. Results are cached briefly (about one minute) so this is not an instant authoritative DNS check. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report
Illustrative example — fixed resolver answers
- Cloudflare: A 192.0.2.10 (TTL 300s)
- Google: A 192.0.2.10 (TTL 240s)
- Quad9: A 192.0.2.20 (TTL 300s)
Signal to review: resolver answers differ. This can be propagation, split-horizon behavior, or a resolver issue; it is not automatically a bad zone.
How to use it
- Enter a domain or DNS name and select the record type.
- Choose Look up DNS to query Cloudflare, Google, and Quad9 independently.
- Compare answer values and TTLs, then review mismatch or resolver-error flags.
- Use the copyable zone-file reference for notes only; edit real records at the authoritative DNS provider.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Services suggested by returned records
These matches describe observed DNS dependencies only. They do not prove an account is active or identify the origin host.
Signals to review
Copy observed answers as a zone-file reference
Rate this tool
What the results mean
Matching values across three recursive resolvers are consistency evidence. Different TTLs alone are normal as caches age. A value mismatch means the resolver views differ. A DNS status or network failure belongs only to that resolver and is not converted into a clean answer.
How it works
The browser sends three parallel DNS-over-HTTPS requests through the bounded endpoint. The response preserves each resolver’s status, typed answers, TTLs, authority context, and errors. Deterministic comparison rules flag differing values or unavailable resolvers, explain the selected record and response status in plain language, identify a small curated set of provider-controlled hostnames only when they appear in returned records, and convert observed answers into zone-style text.
Features
- Ten common record types including PTR and SRV.
- Side-by-side Cloudflare, Google, and Quad9 results.
- Plain-language record and DNS status explanations.
- Evidence-led delivery and email-service hints from returned hostnames.
- TTL, resolver status, and propagation flags.
- Copyable observed-answer reference.
Limitations
These are cached recursive views, not direct authoritative queries, and results are briefly cached by this service. Provider hints cover only a small curated hostname set and do not prove an account is active or reveal an origin. The tool does not trace delegation, edit records, validate DNSSEC chains, test every geographic resolver, or prove the cause of a mismatch.
Frequently asked questions
Why do the three resolvers disagree?
Different recursive resolvers can retain old answers until their TTL expires. A mismatch can indicate propagation, split-horizon DNS, or a resolver failure; it is not by itself proof of a misconfiguration.
Does the zone-file export change DNS?
No. It is a copyable representation of observed answers, not an authoritative export and never a write to your DNS provider.
Which DNS record types can I check?
The checker supports A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV, and PTR. PTR accepts an IPv4 address or a reverse-DNS name.
Are these authoritative DNS answers?
No. Cloudflare, Google, and Quad9 are recursive resolvers. Their cached viewCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. is useful for propagation checks, but the domain’s authoritative nameservers are the source of record truth.
Feature requests for Dns Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Separate a value mismatch from normal TTL aging
Review returned values, DNS status, and time-to-live values so different cache ages are not mistaken for different record content.
Investigate one record type at a time
Check A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV, or PTR evidence for a domain, host, mail policy name, service name, or reverse-DNS address.
Find cautious service-dependency clues
Recognize a small curated set of provider-controlled hostnames only when they appear in returned records, without inferring an active account or origin host.
Create an observed-answer handoff
Copy a zone-style reference for a ticket or review while keeping it clearly separate from an authoritative export or a DNS provider change.
Watch the full workflow
DNS Checker walkthrough
Read the transcript
DNS Checker
This beginner walkthrough explains what D-N-S records and resolvers are, then checks repeatable fictional answers from Cloudflare, Google, and Quad Nine. We will compare record values and T-T-Ls, investigate a propagation-style mismatch, copy an observed-answer reference, recognize a cautious mail-service clue, and read resolver failures without turning them into a false clean result.
Step 1
D-N-S is the directory that connects names with records such as I-P addresses, mail destinations, and verification text. A recursive resolver looks up those records and keeps a cached view. This checker asks Cloudflare, Google, and Quad Nine the same question, side by side. It does not query your provider’s authoritative zone directly.
Step 2
Use it after a D-N-S change, when one network sees a different destination, when you need one specific record type, when returned hostnames may reveal a service dependency, or when a developer needs a copyable evidence record. The important distinction is visible here: these are recursive resolver observations, not an authoritative export.
Step 3
Enter a domain or a more specific D-N-S name, then choose one of ten record types. The help line explains the selected type before you run it. An A record connects a name to an I-P-v-four address. For P-T-R, you can enter an I-P-v-four address and the endpoint converts it to the reverse-D-N-S name.
Step 4
The sample report previews the key pattern. Cloudflare and Google see one fictional address, while Quad Nine sees another. Different T-T-Ls alone can be normal as caches age. A different answer value deserves investigation, but it does not automatically prove the zone is wrong.
Step 5
For the full workflow, enter the reserved fictional name trail dot example dot test and keep A selected. The dot-test suffix cannot be a live customer domain. The capture intercepts all three local endpoint calls with fixed responses, so no public resolver or external site is contacted.
Step 6
Choose Look up D-N-S. The browser sends one bounded request for each named resolver and preserves the result separately. The page then shows three cards instead of merging the answers. That separation matters because a timeout or D-N-S error from one resolver must not be presented as a successful answer from another.
Step 7
All three cards report a successful D-N-S response and one A answer. Cloudflare and Google return one-nine-two dot zero dot two dot ten. Their T-T-Ls differ: three hundred and two hundred forty seconds. Quad Nine returns one-nine-two dot zero dot two dot twenty with a three-hundred-second T-T-L. Compare the answer values first, then the cache timing.
Step 8
The Signals to review section says A answers differ by resolver. Its explanation stays conservative: this can happen during propagation, so compare T-T-Ls and check the authoritative nameservers. The tool identifies the observable difference. It does not guess which answer is intended or why the caches disagree.
Step 9
T-T-L means time to live: a cache-control value carried with a D-N-S answer. Resolver views can show different remaining values because they refreshed at different times. That is why the report does not flag T-T-L variation by itself. The warning appears only because the A-record content differs.
Step 10
Open Copy observed answers as a zone-file reference. The first line says these came through public recursive resolvers and must be verified before publishing. The text keeps the fictional owner name, each observed T-T-L, record class, type, and value. It is useful in a ticket, but it is neither authoritative nor connected to a D-N-S provider.
Step 11
Next, choose M-X. An M-X record names a mail destination, and lower preference numbers are tried first. The help line changes with the selection, which is useful when you know the symptom but are still learning what each record type represents.
Step 12
Run the M-X lookup. All three resolver fixtures return the same preference and Microsoft-controlled mail-protection hostname, although their T-T-Ls vary. No resolver-mismatch signal appears because the record content agrees. The tool also surfaces one service clue derived from that returned hostname.
Step 13
The service section identifies Microsoft Three Sixty Five mail because the returned M-X value ends in its controlled mail-protection domain. The evidence line repeats the exact observed record. The disclosure matters: this suggests a public D-N-S dependency only. It does not prove an account is active, identify the origin host, or discover unrelated vendors.
Step 14
Cloudflare, Google, and Quad Nine each return one successful M-X answer with the same value. This is consistency evidence across three recursive caches at capture time. It is not proof that every resolver worldwide agrees, that mail delivery works, or that the authoritative configuration is correct.
Step 15
For a failure example, run C-NAME. Cloudflare returns one fictional alias. Google returns D-N-S status two, which means server failure. Quad Nine preserves a timeout message. The status line keeps both failures explicit even though neither resolver returned an answer.
Step 16
The Cloudflare card has a successful C-NAME answer to edge dot example dot test. The Google card explains the resolver’s server-failure status. The Quad Nine card states that it did not respond before the timeout. These are different outcomes. Retry and compare other evidence before concluding that the name or record is missing.
Step 17
The browser makes three parallel D-N-S-over-H-T-T-P-S requests through a bounded endpoint. Each result preserves resolver status, typed answers, T-T-Ls, authority context, and errors. Deterministic comparison rules find differing values or unavailable resolvers. Results are briefly cached, so this is not an instant direct query of the authoritative nameservers.
Step 18
The checker supports ten common record types, three side-by-side resolver views, plain-language record and status explanations, cautious delivery and email-service hints, T-T-L and propagation signals, and a copyable observed-answer reference. Each feature stays tied to the returned D-N-S evidence instead of claiming access to a private account or provider.
Step 19
These are cached recursive views, not direct authoritative queries. Provider hints cover only a small hostname list. The tool does not trace delegation, edit records, validate D-N-S-S-E-C chains, test every geography, prove mail delivery, or determine the cause of a mismatch. Confirm the intended record at the authoritative provider, wait for appropriate cache expiry, and re-check from relevant networks.
Use resolver differences as evidence—not a verdict.
Start with the exact record type, value, resolver status, and T-T-L shown in the report. Confirm the intended value at the authoritative D-N-S provider, then decide whether the difference needs a correction or simply more cache time. Re-check from the networks that matter. The copied zone-style text is a review aid; it never changes D-N-S.
Common issues & how to fix them
- Error Requested DNS record is missing Fix: Publish the requested record type at the exact queried name, then verify it from multiple resolvers.
- Error Domain does not exist in DNS Fix: Correct the queried hostname or create its authoritative DNS zone and required records.
- Error Authoritative DNS lookup fails Fix: Repair delegation, DNSSEC, or authoritative nameserver failures until recursive resolvers return a valid answer.
- Warning SPF record is missing Fix: Publish one SPF TXT record at the mail-sending domain that authorizes only the required senders.
- Information DMARC record is not found at this name Fix: Publish a DMARC TXT record at _dmarc on the organizational domain, starting with a monitored policy if needed.
- Information CAA record is absent Fix: Publish CAA records for the certificate authorities allowed to issue certificates for the domain.
- Warning Resolvers return inconsistent answers Fix: Align authoritative answers and wait for TTL propagation until major resolvers return the same record set.