DNS-over-HTTPS Tester

Server assisted New Internet & Network

Asks one DNS question over HTTPS: to Cloudflare 1.1.1.1 or Google Public DNS through their JSON APIs, with the full response code, flags, answer and authority sections and optional DNSSEC data, or to eight public resolvers at once in RFC 8484 wire format to compare their answers. Queries leave from the Cloudflare edge that runs the Mutqan server, so the times are measured there, not from your device.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is DNS over HTTPS?

DNS over HTTPS (RFC 8484) sends ordinary DNS questions and answers inside HTTPS requests, so they are encrypted between the client and the resolver and cannot be read or altered on the way. The records and response codes (RFC 1035) are the same as in classic DNS; Cloudflare and Google also offer a JSON version of the same answers for quick inspection.

How to use DNS-over-HTTPS Tester

  1. Enter a domain name, or an IP address for a reverse lookup. With an IP address the type A or AAAA is replaced by PTR, the record a reverse name holds; other types are asked as chosen.
  2. Choose the record type and the resolver: Cloudflare or Google for a detailed single answer, or All 8 public resolvers to compare.
  3. Tick Ask for DNSSEC records when you want the signatures and the validation flag, then press Query over HTTPS.
  4. Read the response code and flags first, then the records and the findings.

DNS-over-HTTPS Tester features

  • Single-resolver queries to Cloudflare 1.1.1.1 or Google Public DNS over their DoH JSON APIs, with the full response
  • All-resolvers mode: the same question to eight public resolvers in RFC 8484 wire format, answers compared side by side
  • Response code, the AD, CD, TC, RD and RA flags, answer and authority sections with TTLs, and the resolver’s own comment
  • Optional DNSSEC records (DO bit), with a plain reading of the AD flag
  • Sixteen record types, from A, AAAA, MX and TXT to HTTPS, SVCB, CAA, DS, DNSKEY and TLSA; an IP address is looked up by its reverse name, as PTR when A or AAAA was chosen
  • Extended DNS Errors from filtering resolvers shown next to their answers; tables downloadable as CSV

Inputs and outputs

Inputs

  • A domain name (underscore labels such as _dmarc.example.com are accepted) or an IP address, which is queried as its in-addr.arpa or ip6.arpa name (as PTR when A or AAAA is chosen, because a reverse name has no address records).
  • Record type (16 types), resolver (Cloudflare, Google or all eight) and, for one resolver, whether to request DNSSEC records.

Outputs

  • One resolver: resolver, response code, number of records, query time, DNSSEC validation; the answer and authority records with TTLs; the response flags, question and resolver comment.
  • All resolvers: how many answered, whether the answers agree and how many distinct answers there are, the fastest and slowest resolver, and a row per resolver with its status, code, answer, time and any Extended DNS Error.
  • Findings that explain NXDOMAIN, NODATA, SERVFAIL, CNAME chains, the AD flag and the lowest TTL.

DNS-over-HTTPS Tester example

Look up example.com A through Google Public DNS (values change over time)

Input:

Name: example.com · Record type: A · Resolver: Google Public DNS (JSON over HTTPS)

Output:

Resolver: Google Public DNS · Response code: NOERROR · Records: 2 · Query time: 21 ms (from the Cloudflare edge) · DNSSEC validated: yes (AD)
Section | Name | Type | TTL (s) | Data
answer | example.com | A | 300 | 172.66.147.243
answer | example.com | A | 300 | 104.20.23.154
Resolver comment: Response from 172.64.32.162.
Findings:
- AD flag set: the resolver validated the DNSSEC signatures of this answer.
- The lowest TTL is 300 s: resolvers may serve this answer from cache for up to that long after a change (a cached TTL counts down).

How to read the DNS-over-HTTPS Tester results

NOERROR with records is an answer. NOERROR with no records (NODATA) means the name exists without that type; NXDOMAIN means the name does not exist at all.

SERVFAIL from one resolver and an answer from another usually points at DNSSEC: the failing resolver validates and found a broken signature, or its upstream query to the authoritative servers failed.

AD = yes means the resolver checked the DNSSEC signatures. AD = no is normal for an unsigned zone; for a signed zone it is a warning sign.

In all-resolvers mode, different answers right after a change are caching; persistent differences come from geographic DNS, CDNs or filtering resolvers, which often attach an Extended DNS Error saying why.

When to use DNS-over-HTTPS Tester

  • Checking what Cloudflare and Google resolvers return for a record you just changed.
  • Seeing whether a filtering resolver (Quad9, AdGuard, CleanBrowsing) blocks a domain, and the reason it gives.
  • Inspecting the full DNS response — flags, authority section, resolver comments — when a lookup behaves oddly.
  • Confirming that a DNSSEC-signed zone validates (AD set) after a key rollover or a DS change.

Troubleshooting

  • A validation error for the name: only public names and addresses are accepted; private addresses, single labels and internal suffixes such as .local are refused.
  • SERVFAIL from one resolver only: run the DNSSEC Checker on the name, and repeat the query with the other resolver to compare.
  • A rate-limit message: DNS lookups share a per-minute budget per visitor; wait a moment and run the query again.
  • An ANY query returns a single HINFO record: that is RFC 8482 behaviour; ask for the record types you need one by one.

Frequently asked questions about DNS-over-HTTPS Tester

What is DNS over HTTPS?

DNS over HTTPS (DoH, RFC 8484) carries ordinary DNS questions and answers inside HTTPS requests to a resolver, so they are encrypted and look like other web traffic. The answers are the same DNS records a classic lookup returns; only the transport differs.

Does this test whether my browser uses DoH?

No. The queries are sent by the Mutqan server from the Cloudflare edge, not by your browser or operating system, so the page cannot see which resolver your device uses or whether it encrypts DNS. Check the secure DNS setting of your browser or system for that.

What is the difference between the JSON API and RFC 8484 wire format?

Cloudflare and Google also offer a JSON flavour of DoH (application/dns-json and /resolve) that returns the answer as readable JSON; this tool uses it for single-resolver queries because it includes the flags and the resolver’s comments. RFC 8484 sends the binary DNS message itself; the all-resolvers option uses it because every public resolver supports it.

Why do resolvers give different answers?

Right after a change, each resolver may still hold the old answer until its TTL runs out. Sites with geographic DNS or a CDN answer per location, and filtering resolvers such as Quad9, AdGuard and CleanBrowsing block some names on purpose, often with an Extended DNS Error that the table shows.

What does the AD flag mean?

Authenticated Data: the resolver validated the DNSSEC signatures of the answer. It is set only for signed zones whose chain of trust checks out; an unsigned zone never gets it, and that is not an error.

Why is an ANY query answered with one odd record?

RFC 8482 lets resolvers answer ANY with a minimal response instead of every record set, and Cloudflare returns a single HINFO record. Ask for each record type separately.

Technical notes

RFC 8484 defines DoH: a DNS message in the binary format of RFC 1035, sent in an HTTPS request with the media type application/dns-message. The all-resolvers mode uses exactly that, POST to each resolver (GET where a resolver accepts only GET), four resolvers at a time.

The single-resolver mode uses the JSON flavour that Cloudflare (application/dns-json) and Google (/resolve) publish: the same DNS answer, with the header flags, the RCODE and the resolver’s comments as JSON fields. Setting the DO bit asks for RRSIG records; the AD flag reports the resolver’s own DNSSEC validation.

Times are measured by the Mutqan server from the Cloudflare edge that served your request and include the HTTPS connection to the resolver when one had to be opened, so they are not your device’s DNS latency.

Limitations and methodology

Every query is sent from the Cloudflare edge that runs the Mutqan server, not from your device. It shows what the resolvers answer, not which resolver your computer uses or whether it encrypts DNS.

Single-resolver mode covers Cloudflare and Google only; the all-resolvers mode covers eight public resolvers without the flag details.

Times include HTTPS connection setup when a new connection was needed, and anycast resolvers answer from the site nearest to the edge, so they compare resolvers from that vantage point only.

Security and privacy

The name you enter is sent from the Mutqan server to the public resolvers named in the results; resolvers may log queries under their own privacy policies. Mutqan stores nothing.

References