{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

Packet route visual unavailable.

DoH query packet workflow
DoH query and transport setup
Use a public name such as example.com or _443._tcp.example.com.
Address, service, policy, and DNSSEC query types are supported.
Choose a public DoH endpoint or provide a custom HTTPS endpoint.
Example: https://resolver.example/dns-query
GET is cache-friendly and shareable; POST keeps larger packets out of the URL.
Keep IN unless the target and record are intentionally class-specific.
Enter one to four hexadecimal digits; the default 0000 is cache-friendly for DoH.
0x
{{ control.help }}
{{ control.enabled ? 'On' : 'Off' }}
512–4096 bytes; 1232 is a conservative baseline.
bytes
Optional IPv4 or IPv6 prefix, such as 203.0.113.0/24 or 2001:db8::/56.
0–512 zero bytes; larger values can make GET URLs unwieldy.
bytes
Optional comma-separated values from 0–65535; choose DNSKEY first.
1000–30000 ms; the default is 8000 ms.
ms
{{ tableExportAnnouncement }}
FieldValueCopy
{{ row.label }}{{ row.value }}{{ row.value }}
{{ jsonExportAnnouncement }}
{{ chartExportAnnouncement }}
{{ tableExportAnnouncement }}
Replay fieldValueCopy
{{ row.label }}{{ row.value }}
{{ tableExportAnnouncement }}
Response fieldValueCopy
No resolver response yet
The local packet is ready. Send it only when you want the selected resolver to receive this query.
{{ row.label }}{{ row.value }}{{ row.value }}
{{ summaryAnnouncement }}

DNS-over-HTTPS (DoH) carries an ordinary binary DNS message inside an HTTPS request. Encryption protects the exchange while it travels to the chosen resolver, but it does not change the DNS question or hide that question from the resolver. The request still asks for a name, record type, and class; the response still has DNS flags, response codes, section counts, records, and time-to-live values.

Two protocols must be read together during troubleshooting. HTTP describes whether the HTTPS exchange completed and what media type came back. DNS describes whether the name was answered, did not exist, was refused, or failed during resolution. A successful HTTP status can carry an NXDOMAIN or SERVFAIL DNS response, so HTTP 200 is not proof that the requested record exists.

Wire message
The DNS header, question, and optional EDNS data encoded as bytes.
DoH GET
The wire bytes are unpadded base64url data in the dns query parameter. Equivalent requests are easier for HTTP caches to recognize.
DoH POST
The wire bytes are the request body with media type application/dns-message. Larger messages stay out of the URL.
EDNS
An OPT pseudo-record that carries extension flags and options such as DNSSEC OK, Client Subnet, padding, keepalive, or DNSKEY key tags.

Packet crafting is useful when a normal lookup hides too much detail: reproducing a resolver problem, comparing GET and POST encodings, checking DNSSEC flags, studying EDNS options, or saving a byte-exact request for another client. The extra control also creates extra ways to misread a test. The Checking Disabled flag asks the recursive resolver not to validate; the DNSSEC OK bit asks for DNSSEC records. Neither flag proves that an answer is authentic.

Resolver answers can vary with cache state, location, resolver policy, DNSSEC validation, and EDNS Client Subnet (ECS). ECS can influence location-sensitive answers by disclosing a network prefix, while padding changes request size without changing the question. Repeat comparisons with the same name, type, flags, endpoint, and options when the transport method is the only variable under test.

How to Use This Tool:

Build the smallest packet that answers the test question, then add EDNS or DNSSEC controls one at a time so their effects remain visible.

  1. Enter a public DNS name and choose the record type. Keep Query class on IN unless the target intentionally uses another DNS class.
  2. Select a public resolver or provide a complete custom HTTPS endpoint, then choose GET or POST. Leave the message ID at 0000 when cache-friendly DoH comparison matters.
  3. Set Recursion desired, Checking disabled, EDNS, and DNSSEC OK for the specific experiment. Adding an EDNS option or enabling DNSSEC OK automatically adds the OPT record.
  4. Review the exact packet size, header flags, option summary, wire hex, and HTTP replay data before sending anything.
  5. Choose Send live query only when the selected resolver should receive the request. Compare the HTTP status with the DNS response code, message ID, flags, section counts, and returned records.
An ECS value sends the normalized network prefix to the resolver. Omit it unless location-sensitive resolution is the subject of the test.

Interpreting Results:

HTTP and DNS result signals in a DoH response
Signal What it establishes What it does not establish
HTTP status Whether the DoH exchange was accepted at the HTTP level Whether DNS found an answer
DNS response code The resolver's DNS outcome, such as NOERROR, NXDOMAIN, or SERVFAIL Whether the answer is authoritative or DNSSEC-validated
AD flag The recursive resolver reports authenticated data under its validation policy An independent end-to-end validation by the browser
Message ID match The decoded response carries the same ID as the request That the returned names and records are correct

Read answer, authority, and additional records together with their TTLs. Zero answer records can be valid for a referral, an authenticated denial, or a query type whose useful evidence appears outside the answer section. Unknown record types remain visible as hexadecimal data rather than receiving a guessed interpretation.

A browser failure against a custom endpoint does not invalidate the locally built packet. The endpoint may reject cross-origin browser requests even when the same bytes work from a command-line client. Replay the generated GET or POST command outside the browser before blaming DNS encoding.

Technical Details:

A DoH request starts as the DNS wire format defined for datagram messages. The fixed 12-byte header is followed by one question. An OPT pseudo-record appears in the additional section when EDNS is explicitly selected, the DNSSEC OK bit is set, or any EDNS option is present. HTTPS then transports the same bytes without a TCP-style two-byte DNS length prefix.

Transformation Core

DoH packet construction stages
Stage Encoding rule Produced artifact
Name Lowercase the query name, remove one trailing dot, and encode each ASCII label as a length byte followed by its bytes, ending with zero. QNAME
Question Append the unsigned 16-bit record-type code and class code. QNAME + QTYPE + QCLASS
Header Encode the message ID, RD and CD flags, one question, no answers or authority records, and one additional record only when EDNS is effective. 12-byte DNS header
EDNS Add root owner name, type 41, advertised payload, DO flag, option-data length, and encoded options. OPT pseudo-record
HTTP For GET, base64url-encode the complete message without = padding. For POST, use the raw message as the body. Replay URL or request body

Rule Core

  • A DNS label must contain 1 to 63 ASCII or punycode characters, and the normalized full name must not exceed 253 characters.
  • The message ID accepts one to four hexadecimal digits and is encoded as an unsigned 16-bit field.
  • RD sets header bit 0x0100; CD sets 0x0010. DO is not a header bit. It is bit 0x8000 in the OPT TTL flags field.
  • The advertised EDNS payload is 512 to 4,096 bytes. The locally constructed message is rejected when its total size exceeds that value, although DoH itself transports the message over HTTPS rather than UDP.
  • Live timeouts range from 1,000 to 30,000 milliseconds. Padding ranges from 0 to 512 zero bytes.
Supported EDNS options and their encoding rules
Option Code Payload rule
Client Subnet 8 Encode address family, source prefix, zero scope prefix, and only the network bits required by the prefix.
TCP keepalive 11 Send a zero-length request option.
Padding 12 Append the selected number of zero bytes.
DNSKEY key tag 14 Encode each tag as an unsigned 16-bit value; accepted only for a DNSKEY query.

Privacy and Safety Notes:

The packet is assembled locally. No resolver receives it until Send live query is used. After sending, the selected resolver can read the DNS question and EDNS options, and the browser establishes a network connection to that endpoint. HTTPS protects the request in transit but does not conceal it from the resolver.

  • GET places the encoded question in a URL, which can be retained by browser history, logs, or intermediaries. POST keeps the packet in the request body.
  • ECS exposes the chosen network prefix and may change both resolver behavior and cache partitioning.
  • Do not aim custom endpoints at systems you are not authorized to test. A crafted query is still network traffic when it is sent.

Worked Examples:

Cache-friendly address query

Query example.com for an IN A record with message ID 0000, RD on, and no EDNS options. The packet contains the 12-byte header and one question. GET carries its unpadded base64url form in the URL; POST carries the same bytes in the body. A live result still needs both an HTTP success and a DNS response code review.

DNSSEC query with an ECS warning

Choose DNSKEY, enable DNSSEC OK, and add an IPv4 prefix such as 203.0.113.0/24. EDNS becomes effective, the DO flag enters the OPT record, and ECS option 8 carries only the prefix bytes. The request is useful for inspecting resolver behavior, but the ECS warning matters because the resolver receives that network hint.