Cloudflare
cloudflare-dns.com, 1.1.1.1
Waiting
,
Enter a domain and press Look up. The two answers appear here, side by side.
Pikkola DNS & Network Studio, tool No. 18
One name. Two resolvers. The same answer, or not.
Ask Cloudflare and Google the same question and you see what the world sees, not what your laptop cached an hour ago. Every lookup here is two real DNS-over-HTTPS requests, timed side by side, with the SPF and DMARC policy of the domain read in the same visit.
Look up a domain
no account, no upload
- 8
- record types
- 2
- public resolvers
- 0
- queries logged by us
Lookup
The record, from two places at once.
Both resolvers get the same DNS-over-HTTPS question. The times are measured in your browser, so they include your own connection, which is the number your users will feel. The TTL is how long each resolver is allowed to keep the answer after this.
Try
Match
Waiting
,
Enter a domain and press Look up. The two answers appear here, side by side.
How to read the verdict
- Match Both caches hold the same set. The record has reached both networks, so the change has landed for the people behind them.
- Answers differ One cache is still serving the old TTL, or the zone holds two records that contradict each other. Check again after the old TTL has passed.
- One resolver down The other answer is still worth reading, but a comparison needs both of them.
Mail policy
SPF says who may send. DMARC says what to do when someone else does.
Both are TXT records, both are easy to publish half right. This reads the record on the domain and the one under _dmarc, then says what the policy actually allows and what it leaves open.
SPF
TXT pikkola.comPress Read mail records to fetch the policy for the domain above.
DMARC
TXT _dmarc.pikkola.comPress Read mail records to fetch the policy for the domain above.
Why this one
A cached answer is still an answer. Just not always today's.
The difference is the useful part.
One resolver tells you what one cache believes. Two large resolvers on separate networks tell you whether a change has landed everywhere, which is the question behind every "it works on my machine" DNS ticket.
BIND, not a screenshot.
The copy button gives you zone lines with the name, the TTL and the class in order, so the answer can go straight into a zone file or a change request instead of being retyped from a browser window.
Your browser does the asking.
The two requests go from your tab to Cloudflare and Google, not through a server of ours. There is no account, no history and no place where a list of the domains you checked could pile up.
Reference
What each record type is for
Eight types cover almost every lookup a person makes by hand. The mistakes in the right column are the ones that show up in real tickets.
| Type | What it holds | Usual mistake |
|---|---|---|
| A | The IPv4 address of a name. | Two addresses where one is an old server nobody turned off. |
| AAAA | The IPv6 address of a name. | Published by the host, but blocked by a firewall that was never opened. |
| CNAME | Another name that this name follows. | A CNAME on the same name as an MX or TXT record, which the standard does not allow. |
| MX | The mail servers for the domain, each with a preference number. | Two servers with the same preference, so senders pick in no order. |
| TXT | Free text: SPF, DMARC, site verification, DKIM keys. | Two SPF records instead of one, which breaks both. |
| NS | The name servers that answer for the zone. | Changing them at the registrar but leaving old records at the old provider. |
| SOA | The zone's authority record: primary server, contact, serial, timers. | A serial number that only goes up on one of two name servers. |
| CAA | Which certificate authorities may issue for the domain. | A list that leaves out the CA actually in use, so renewals fail. |
Two companies see the question. Nobody sees you.
A DNS lookup cannot be answered without asking someone. The domain you type goes to Cloudflare and Google, and nowhere else. There is no account, no analytics and no log of ours to read.
Questions
Asked while waiting for a TTL
Where do these answers come from?
From two public DNS-over-HTTPS services. Cloudflare answers at cloudflare-dns.com and Google answers at dns.google. Your browser calls both directly, in parallel, and times each one. There is no server of ours in between, so nothing is cached or logged on the way.
Why two resolvers and not ten?
Two large resolvers with separate networks catch the case that matters most: a record that was changed recently and has reached one cache but not the other. Adding more resolvers mostly adds traffic, not information, and every extra one is another company that learns which domain you asked about.
Is a difference between the two a problem?
Usually it is propagation. A new record carries the TTL of the old one, so each resolver keeps its copy until that runs out, and they expire at different moments. If the difference is still there after the old TTL has passed twice, the zone itself is probably inconsistent, for example a CNAME and an A record on the same name.
Why is there no DKIM check?
A DKIM public key sits at a name that includes a selector the domain chose, such as google._domainkey or s1._domainkey, and the DNS cannot list which selectors exist. A check without the selector would report keys that are not there. SPF and DMARC have fixed names, so both can be read exactly.
Do you keep a history of what I look up?
No. There is no account, no analytics and no server log of ours. The domain you typed goes to Cloudflare and Google because that is the question being asked, and their own privacy terms apply to it. The last domain and record type stay in your browser's local storage so the page opens where you left it, and you can clear that with the browser's site data.
Can I look up a domain I do not own?
Yes. The DNS is public by design, and this is the same information any resolver would return. Only private zones, such as an internal split-horizon DNS, will look different here, because public resolvers cannot see them.
Made by one person, free to use