DoH Query Packet Crafter

Sending {{ transportLabel }} packet to {{ resolverRuntimeLabel }}...

Query name:

Use example.com, _443._tcp.example.com, version.bind, or a URL host.

Record type:

Choose A/AAAA for addresses, TXT/MX/SRV for service records, or DNSSEC types for trace work.

Resolver path:

Cloudflare and Google usually allow browser sends; custom endpoints need CORS.

Custom resolver URL:

Use a full HTTPS DoH endpoint, usually https://host/dns-query.

Transport method:

Use GET for shareable URLs; POST for larger EDNS or padded packets.

Packet preset:

Choose Custom to keep current values, or apply a preset to overwrite related fields.

Message ID mode:

Use random for normal replay; fixed hex for byte-for-byte comparisons.

Fixed ID hex:

Accepted: 1 to 4 hex digits, with or without 0x.

{{ warning }}

Query class:

Use IN for public DNS records; CH for version.bind-style diagnostics.

Recursion desired:

Leave on for ordinary DoH lookups through public resolvers.

Checking disabled:

Use only when diagnosing validation failures; normal lookups leave it off.

Include EDNS OPT:

Turn on when any EDNS option or DNSSEC DO behavior matters.

DNSSEC DO bit:

Enable for DS, DNSKEY, RRSIG, NSEC, and validation traces.

UDP payload size:

bytes

512 {{ udp_payload }} bytes 4096

Accepted range: 512 to 4096 bytes; 1232 is a common DoH-safe baseline.

ECS hint:

Accepted: IPv4/prefix or IPv6/prefix, for example 203.0.113.0/24.

Padding bytes:

bytes

0 {{ padding_bytes }} bytes 512

Accepted range: 0 to 512 bytes; padding makes GET URLs longer.

TCP keepalive:

Leave blank to omit; values are milliseconds from 0 to 65535.

Key tags:

Use comma or space-separated integers from 0 to 65535.

Live timeout:

1000 {{ timeout_ms }} ms 30000

Accepted range: 1000 to 30000 ms; packet crafting is unaffected.

Field	Value	Copy
{{ row.label }}	{{ row.value }}
Packet note {{ index + 1 }}	{{ note }}
Wire hex	{{ packetHexPretty }}
Base64url GET payload	{{ packetBase64Url }}

Flag	Value	Copy
{{ row.label }}	{{ row.value }}
EDNS {{ row.code }} {{ row.option }}	{{ row.value }} ({{ row.bytes }} bytes)
EDNS options	No EDNS options are attached to this packet.

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Field	Value	Copy
No live resolver response yet Use Send Live from the query-name row to capture HTTP headers, DNS flags, section rows, and response hex.
{{ row.label }}	{{ row.value }}
Header: {{ row.label }}	{{ row.value }}
HTTP headers	No HTTP headers were captured.
{{ row.section }} {{ row.type }}	{{ row.name }}; TTL {{ row.ttl }}; {{ row.data }}
Section ledger	The response decoded cleanly, but no answer, authority, or non-OPT additional records were present.
Response flag: {{ row.label }}	{{ row.value }}
Response hex	{{ responseHexPretty }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

DNS-over-HTTPS changes the transport, not the question. The resolver still receives a DNS wire-format message with a header, question section, optional extension data, and the same response-code vocabulary used by ordinary DNS. HTTPS adds encryption, headers, caching behavior, and browser security rules around that message.

That distinction is the source of many DoH debugging mistakes. A request can return HTTP 200 while the DNS response says NXDOMAIN, SERVFAIL, REFUSED, or contains no answer records. A resolver can also accept a DNSSEC-related request without setting the Authentic Data flag, or receive an EDNS Client Subnet hint without using it in the final answer. Reading the HTTPS status alone hides the DNS decision.

Packet-level DoH work usually appears in a few practical situations: reproducing a browser lookup in another client, comparing GET and POST request shapes, checking whether EDNS options survive the path to a resolver, and saving exact evidence for a DNSSEC or location-sensitive answer. In each case, the useful artifact is not just a domain name lookup. It is the byte sequence, flags, request wrapper, and decoded reply kept together.

DNS question fields, EDNS options, and an HTTPS wrapper kept as separate DoH debugging signals

Three terms help keep the work clear. The DNS wire message is the binary request and response format. EDNS adds extension data through an OPT pseudo-record inside that message. The DoH request is the HTTPS exchange that carries the DNS message by GET or POST. Confusing those parts can lead to false conclusions, such as blaming HTTPS when the DNS response code is the real failure.

DoH packet concepts and common interpretation mistakes
Concept	What it means	Common mistake
Question	QNAME, QTYPE, and QCLASS define the record being requested.	Using the right resolver while asking the wrong record type.
Header flags	Bits such as RD and CD ask for recursion or alter validation behavior.	Assuming a flag request proves the resolver honored it.
EDNS options	Optional data such as payload size, DNSSEC OK, ECS, padding, keepalive, and key tags.	Treating optional resolver behavior as a guaranteed contract.
HTTP wrapper	The HTTPS method, headers, URL, and response status around the DNS bytes.	Reading HTTP success as DNS success.

A reliable DoH test keeps these concepts visible at the same time. The packet bytes make the request reproducible, the replay data shows how HTTPS carries it, and the decoded resolver reply shows what DNS actually answered.

How to Use This Tool:

Start with the DNS question, then choose the resolver and request wrapper. Live sending is optional; packet construction and replay evidence are useful even before a resolver is contacted.

Enter a Query name and choose the Record type. Hostnames such as example.com, service names such as _443._tcp.example.com, version.bind, and pasted URL hosts are accepted after normalization.
Select the Resolver path. Use Cloudflare or Google for common browser-send tests, or choose Custom DoH endpoint when you need a full HTTPS resolver URL for a private or lab endpoint.
Choose Transport method. GET creates a replay URL with the DNS payload in the query string; POST sends the raw DNS message as an application/dns-message body.
GET is convenient for sharing and cache-style experiments. POST is usually better for DNSSEC traces, padding, and larger EDNS packets because the DNS bytes are not carried in the URL.
Pick a Packet preset when you want a starting posture such as lean GET lookup, DNSSEC trace, validation bypass, or ECS probe seed. Use Message ID mode and Fixed ID hex when byte-for-byte comparisons need the same 16-bit DNS ID on repeated builds.
Open Advanced only for fields that change resolver behavior or packet shape: query class, recursion desired, checking disabled, EDNS OPT, DNSSEC DO bit, UDP payload size, ECS hint, padding bytes, keepalive timeout, key tags, or live timeout.
Review DNS Wire Packet, DNS Flag Ledger, and DoH HTTP Replay before sending. The packet bytes, base64url payload, request headers, EDNS rows, and replay commands should match the test you meant to run.
If the packet will not build, check for an empty or whitespace-containing query name, an invalid custom HTTPS URL, fixed ID text that is not 1 to 4 hex digits, or out-of-range numeric fields.
Press Send Live only when the selected resolver should receive the complete DNS message. Resolver Response Ledger then reports HTTP status, response headers, DNS response code, response flags, record sections, and response hex.
Save the evidence you need after the DNS response code, ID match, answer rows, and replay commands look consistent. A browser network failure or CORS rejection does not invalidate the locally built packet.

Interpreting Results:

The packet size and request badges describe the query before it leaves the browser. The useful live answer is the decoded DNS response, especially DNS response code, answer count, ID match, Content-Type, AD/RA/TC flags, and the answer, authority, and additional sections. Check those fields before deciding that a resolver accepted, refused, validated, or ignored a request.

Do not overread a single success cue. HTTP 200 means the HTTPS exchange completed; it does not mean the DNS question returned useful records. A matching message ID confirms correlation with the query, but it does not prove the records are correct for every resolver or vantage point. ECS, DNSSEC, and validation-bypass tests are especially sensitive to resolver policy.

DoH response cues and interpretation guidance
Result cue	What to trust	What to verify next
HTTP status	Whether the HTTPS request completed and returned a body.	DNS response code and whether the body decoded as DNS wire format.
DNS response code	Whether the DNS question was answered, failed, refused, or named a nonexistent owner.	Answer count and section rows, because NOERROR can still have no useful answer.
Flag ledger	Which request bits and EDNS options were encoded in the query.	Returned flags such as AD, RA, TC, and whether EDNS data appears in the response.
Replay data	The exact GET URL, POST endpoint, request headers, and command-line replay shape.	Whether GET length, URL logging, or POST body handling fits the environment.
ID match	Whether the decoded response carries the same DNS message ID as the current request.	Resolver body size, Content-Type, and response hex when the answer looks unrelated.

For repeat comparisons, keep the query name, record type, resolver, transport, message ID policy, EDNS options, and timeout the same. Change only one setting at a time when you want to isolate whether DNSSEC, ECS, padding, validation bypass, or resolver choice caused the difference.

Technical Details:

DNS wire format, defined by the core DNS specifications, begins with a 12-byte header followed by question, answer, authority, and additional sections. A normal query usually has one question containing QNAME, QTYPE, and QCLASS. Header flags ask for behavior such as recursion, while response flags report resolver-side facts such as recursion availability, truncation, and authentic data.

DoH maps that DNS message into an HTTPS exchange. RFC 8484 defines GET and POST forms for the application/dns-message media type. EDNS, from RFC 6891, extends the DNS message by placing an OPT pseudo-record in the additional section. DNSSEC OK, EDNS Client Subnet, padding, keepalive, and key-tag signaling all need that EDNS carrier when they are present.

Transformation Core:

The core operation is a deterministic packet transformation, not a numeric calculation. The same DNS question can produce different byte strings when the message ID, EDNS options, padding, or transport wrapper changes.

How visible DoH inputs become packet and replay evidence
Stage	Mechanism	Visible evidence
Name and question	The query name is trimmed, URL-like input is reduced to its host, a trailing dot is removed, and whitespace is rejected. QTYPE and QCLASS complete the question.	Question summary, wire hex, and base64url payload.
Header	A 16-bit DNS ID is generated randomly or set from a fixed hex value. RD and CD bits are encoded when selected.	Message ID, Recursion desired, Checking disabled, and ID match after a live reply.
EDNS attachment	An OPT pseudo-record is added when EDNS is requested or when DO, ECS, padding, keepalive, or key tags require one.	EDNS attached, UDP payload size, Additional count, and EDNS option rows.
GET or POST wrapper	GET base64url-encodes the DNS bytes into the DoH URL. POST sends the same bytes as the request body with DNS-message headers.	GET endpoint, POST endpoint, request headers, body bytes, and replay commands.
Live decode	A resolver response body is interpreted as DNS wire format when possible and separated into summary rows, flags, and record sections.	HTTP status, DNS response code, Content-Type, response flags, section rows, and response hex.

Protocol Fields and Bounds:

DoH packet fields, meanings, and validation bounds
Field or option	Meaning	Bound or caution
QTYPE	Names the requested record type, including A, AAAA, MX, TXT, SRV, TLSA, DS, DNSKEY, RRSIG, NSEC, NSEC3, ANY, and AXFR.	ANY and AXFR are commonly restricted or answered differently by public resolvers.
QCLASS	Uses IN for ordinary Internet DNS, with CH and HS available for specialized diagnostics.	CH is useful for `version.bind`-style checks; it is not a normal public-record class.
Message ID	Identifies the DNS message in the header.	Fixed mode accepts 1 to 4 hex digits, with or without `0x`.
UDP payload size	Advertises the EDNS response payload size.	Accepted range is 512 to 4096 bytes; 1232 bytes is the default baseline used by the presets.
ECS option 8	Carries an IPv4 or IPv6 client subnet prefix for location-sensitive answer experiments.	Accepted form is address/prefix, such as `203.0.113.0/24` or `2001:db8::/56`.
Keepalive option 11	Signals an EDNS TCP keepalive timeout value.	Accepted range is 0 to 65535 ms; DoH connection handling is still governed by HTTP behavior.
Padding option 12	Adds zero-byte padding to change DNS message size.	Accepted range is 0 to 512 bytes; padding can make GET URLs long.
Key Tag option 14	Carries DNSSEC key-tag values for resolver diagnostics.	Each key tag is a 16-bit integer, and resolvers may ignore the signal.
Live timeout	Limits how long the browser waits for the selected resolver.	Accepted range is 1000 to 30000 ms; timeout does not change locally built packet evidence.

GET and POST Semantics:

GET and POST can carry the same DNS wire message, but they create different operational evidence. GET is compact and shareable for small queries because the encoded DNS message is visible in the URL. POST keeps the binary message in the body and is better suited to DNSSEC, padding, and other tests that increase packet size.

GET replay data can appear in browser history, proxy logs, screenshots, and ticket systems because the payload is part of the URL.
POST replay uses the same DNS bytes but sends them as the request body, along with an application/dns-message content type.
Changing a random message ID changes the packet bytes and the GET payload even when the question and flags are otherwise identical.
A DoH response body may be a valid DNS message with a negative response code, or it may fail DNS decoding even when the HTTP exchange completed.

Privacy and Safety Notes:

Packet previews, wire hex, base64url payloads, replay commands, and JSON evidence are built in the browser. Pressing Send Live sends the complete DNS message to the selected resolver over HTTPS, including the query name, record type, flags, EDNS options, ECS prefix, padding, and key tags you entered.

GET replay URLs can expose the encoded DNS query in copied links, browser history, server logs, and screenshots.
ECS deliberately discloses a network prefix. Use the least-specific prefix that still answers the routing question.
Custom resolver sends depend on browser CORS policy. A failed browser send may still replay correctly from cURL or another client.
DNSSEC flags are diagnostic inputs. DO and CD do not turn a resolver reply into independent cryptographic proof by themselves.

Worked Examples:

These examples show how packet choices change the evidence a DNS engineer should read.

Small address lookup

For example.com with A, IN, RD on, and the lean GET preset, the main artifacts are a short wire packet, a base64url replay URL, and a DNS response code after live sending. HTTP 200 is only the transport result; the answer rows still need to show the address records or the reason they are missing.

DNSSEC trace with response flags

A DS or DNSKEY lookup with EDNS and the DO bit enabled should add an OPT pseudo-record and ask for DNSSEC material. The useful reading comes from the flag ledger, response sections, and AD flag together. DO means DNSSEC records were requested; it does not prove that the resolver validated the answer.

ECS probe with a safer replay choice

An ECS hint such as 203.0.113.0/24 appears in the EDNS option rows and may influence location-sensitive answers. If DNSSEC data or padding makes the GET URL long, switch the transport to POST before sharing the replay evidence so the DNS message is not exposed in a long URL.

Custom resolver browser failure

A custom HTTPS resolver can build a valid packet and still fail when Send Live runs because the endpoint rejects browser-origin requests. In that case, keep the wire packet and POST replay command, then test the same bytes from a command-line client to separate packet validity from browser policy.

FAQ:

Why did HTTP 200 still show a DNS error?

HTTP 200 means the HTTPS request returned successfully. The DNS response code inside the body still decides whether the DNS name existed, failed, was refused, or returned useful records.

Why did an OPT record appear when Include EDNS OPT was off?

DO, ECS, padding, keepalive, and key-tag data all require EDNS. If any of those options are active, the query needs an OPT pseudo-record to carry them.

When should I use a fixed message ID?

Use a fixed hex ID when byte-for-byte packet comparison matters. Use random IDs when each build should behave like a fresh DNS query.

Why might a custom resolver fail in the browser?

The resolver may not allow browser-origin requests, may require a different endpoint, or may return a response that is not application/dns-message. The replay command lets the same packet be tested outside the browser.

Does the DNSSEC DO bit validate the answer?

No. DO asks for DNSSEC-related records when available. Validation confidence comes from resolver behavior, returned records, response flags such as AD, and independent DNSSEC checks when the result is security-sensitive.

Glossary:

DoH: DNS-over-HTTPS, a protocol for carrying DNS wire messages in HTTPS exchanges.
DNS wire format: The binary DNS message structure used by DNS queries and responses.
QTYPE: The record type requested in the DNS question, such as A, AAAA, MX, TXT, DS, or DNSKEY.
RCODE: The DNS response code, such as NOERROR, NXDOMAIN, SERVFAIL, or REFUSED.
EDNS: Extension Mechanisms for DNS, carried in an OPT pseudo-record.
OPT pseudo-record: A DNS additional-section record that carries EDNS payload size, flags, and options.
DNSSEC DO bit: The EDNS DNSSEC OK bit that asks for DNSSEC-related response data.
ECS: EDNS Client Subnet, an option that sends an address prefix for location-sensitive DNS behavior tests.

References:

RFC 1035: Domain Names - Implementation and Specification, RFC Editor, November 1987.
RFC 8484: DNS Queries over HTTPS (DoH), RFC Editor, October 2018.
RFC 6891: Extension Mechanisms for DNS (EDNS(0)), RFC Editor, April 2013.
RFC 7871: Client Subnet in DNS Queries, RFC Editor, May 2016.
RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor, March 2005.
RFC 7830: The EDNS(0) Padding Option, RFC Editor, May 2016.
How to query DNS records in Windows, Simplified Guide.