DNS-over-HTTPS Privacy Query Tester

Resolve a domain via Cloudflare or Google DoH and compare the answers side by side

Perform an A/AAAA DNS lookup for any domain through the Cloudflare (1.1.1.1) and Google (8.8.8.8) DNS-over-HTTPS endpoints directly from your browser with fetch(). Compare the resolved IPs from both resolvers, inspect TTLs and the response status, and verify that encrypted DoH answers match — no API key required. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is DNS-over-HTTPS (DoH)?

DoH sends DNS queries inside an encrypted HTTPS request instead of plain UDP port 53. This stops on-path observers from seeing or tampering with which domains you look up, improving privacy on shared and untrusted networks.

This tester resolves a domain through two major DNS-over-HTTPS providers — Cloudflare and Google — straight from your browser, so you can confirm that encrypted DoH resolution works and that both resolvers agree on the answer.

How it works

Both Cloudflare and Google publish a JSON DoH API following the same query shape. A request looks like:

GET https://cloudflare-dns.com/dns-query?name=example.com&type=A
Accept: application/dns-json

The tool issues that request (and the Google equivalent at https://dns.google/resolve) with fetch(). The JSON response includes:

  • Status — the DNS RCODE (0 = NOERROR, 3 = NXDOMAIN, 2 = SERVFAIL).
  • Answer — an array of records, each with a name, numeric type, TTL, and data (the IP for A/AAAA records).

The tool parses both responses, lists the resolved addresses with their TTLs, and flags whether the two resolvers returned the same set of IPs.

Reading the results

A matching answer from both resolvers means your DoH path is clean and consistent. A mismatch is not automatically a problem — content delivery networks return geo- and load-based answers — but a consistent mismatch, or a NXDOMAIN from only one provider, is worth investigating. If one query fails entirely while the other succeeds, the failing provider may be blocked on your network.

Notes

  • The browser cannot read your operating system’s resolver directly, so this compares two encrypted public resolvers rather than DoH-vs-system. To compare against system DNS, run nslookup or dig locally and check the IPs against what you see here.
  • A short TTL (a few seconds to a minute) means the record rotates often; re-running the query may yield different but valid IPs.
  • All queries go directly from your browser to the public resolvers. No data passes through any Gera server.

Why DoH matters in practice

Traditional DNS queries travel over UDP port 53 in plain text. Any network intermediary — a public Wi-Fi router, an ISP, or a corporate proxy — can read the domain names you look up even if the connection to the site itself is HTTPS. DNS-over-HTTPS wraps those queries in an encrypted HTTPS request to a trusted resolver, making query contents invisible to on-path observers.

For developers and sysadmins, DoH is useful in several contexts:

  • Verifying bypass of local DNS hijacking. Some networks intercept all port-53 traffic to enforce filtering. Querying via DoH from your browser reaches Cloudflare or Google directly, confirming whether an unfiltered answer is reachable.
  • Testing propagation from a specific resolver. When you push a DNS change, Cloudflare and Google cache independently. Querying both simultaneously shows whether one has picked up the new record while the other still serves a stale TTL.
  • Debugging CDN and geo-DNS. Some CDNs return different IP addresses based on the resolver’s location. Because Cloudflare’s DoH resolver sits at edge nodes worldwide and Google’s resolves from its own anycast network, they sometimes return different but valid A records for the same hostname.

Interpreting common scenarios

Cloudflare resultGoogle resultLikely explanation
NOERROR + IPsNOERROR + same IPsClean resolution, records propagated to both
NOERROR + IPsNOERROR + different IPsGeo-DNS or CDN load-balancing; both valid
NOERRORNXDOMAINOne resolver has stale cache; wait for TTL expiry
Both SERVFAILBoth SERVFAILDNSSEC validation failure or authoritative server problem
NOERRORSERVFAILPossible DNSSEC inconsistency in the zone

A SERVFAIL that only appears on a validating resolver (Cloudflare validates by default, Google supports it too) often points to a broken DNSSEC signature rather than a missing record.