DNS Message Decoder

Both, and that is the point. The rcode started as four bits in the header, and EDNS0 widened it to twelve by putting the upper eight in the TTL field of the OPT record. A decoder that reads only the header nibble sees the low four bits of 16 — which are zero — and reports NOERROR, so a resolver rejecting your EDNS version looks like a perfectly fine empty answer. Any message with an OPT record has to combine the two halves, which is what happens here; the extended rcode is also shown on its own in the EDNS0 panel so you can see where the extra bits came from.

It is the whole wire-format message — the same bytes that would go in a UDP packet — encoded with base64url and, per RFC 8484, with the padding stripped. That is why it uses - and _ instead of + and /: it has to survive being a URL query parameter. Two details trip people up. The message id should be 0 in a GET request so that identical queries produce identical URLs and can be cached by HTTP; and the answer comes back as a raw application/dns-message body, not JSON, so what you copy out of the network panel is binary that has to be turned into hex before you can read it. Paste either form here.

A pointer names an offset in the message where the rest of a name can be found, and RFC 1035 requires it to point at a prior occurrence. Backward-only is not a style preference: it is what guarantees the chase terminates. A pointer to itself, or to any later offset, lets a two-byte crafted packet spin a naive decoder forever, and packets built exactly that way circulate as denial-of-service tests. So a forward or self-referential pointer is reported as the fault it is rather than followed, and the number of jumps is capped even for backward chains.

All of them, joined end to end with nothing between. TXT rdata is a sequence of character-strings, each with a one-byte length, so no single string can exceed 255 bytes; anything longer — a DKIM public key, a long SPF policy — has to be split, and the receiver concatenates. That is why a DKIM record often looks like two fragments that break mid-base64. The strings are shown separately here because the split is really in the packet, and because a record whose author meant them as separate values is a bug you can only see when they are not run together.

An HTTPS or SVCB record is a priority, a target name and a list of key/value SvcParams: alpn for the protocols the server speaks, port, ipv4hint and ipv6hint for addresses to try while the A and AAAA lookups are still in flight, ech for the encrypted client hello configuration. The wire format requires the params to be in ascending key order with no duplicates, which is what makes them cheap to parse and what a hand-built record most often gets wrong. A record whose keys are out of order is malformed, so it is shown as raw hex here rather than silently reordered into something that looks correct.

No, and nothing that only reads one packet could. An RRSIG is checked against the DNSKEY of the zone, which has to be fetched and then chained up through DS records to a trust anchor you already trust; a TSIG is checked with a shared secret that by definition never travels in the message. What you do get is everything the bytes themselves say: which RRSIG covers which type, its inception and expiry as real timestamps, the key tag and signer name to compare against the DNSKEY set, and whether the AD bit was set — which records only that some resolver upstream claims it validated, not that it did.