Input / 03
Bring the DNS message, not the whole capture.
The inspector accounts for one DNS payload from byte zero to its declared end.
Reviewed October 25, 2026
Accepted inputs
- Hex
- Pairs of hexadecimal digits, optionally separated by whitespace. Remove hexdump addresses, ASCII columns and
0xprefixes first. - Base64
- Standard padded Base64. Do not include a data-URL prefix. Base64url and non-canonical padding are rejected.
- Binary file
- Choose “DNS wire · binary file” before selecting a file containing exactly one DNS message.
- TCP framing
- If the file includes the two-byte TCP message-length prefix, select the explicit checkbox. The declared length must match the entire remaining input. The prefix is reported separately.
PCAP, Ethernet frames, IP packets, UDP headers, TLS records, HTTP bodies containing JSON and concatenated TCP messages are not accepted as DNS payloads. Extract the message using the capture tool you already trust. WireBudget never opens a network connection to fetch it.
What the accounting includes
The 12-byte DNS header is followed by the questions and resource records declared by its counts. A question contains an encoded name, a type and a class. A resource record adds a 10-byte fixed envelope after its owner name, followed by its declared RDATA. The DNS wire specification defines those fields.
The ruler counts the bytes actually present. A compressed owner pointer occupies two bytes even if its expanded name is much longer. The reader follows backward name pointers with bounds and loop checks. It rejects unsupported label encodings, oversized names and input that ends inside a field.
A worked synthetic layout
| Part | Bytes | Why |
|---|---|---|
| Header | 12 | Six two-byte fields |
| Question | 17 | 13-byte lab.example. name + type/class |
| A record | 16 | 2-byte owner pointer + 10-byte envelope + 4-byte value |
| RRSIG record | 2463 | 12-byte envelope/name + 31-byte signature metadata + 2420-byte signature |
| OPT | 11 | Root owner and fixed EDNS fields, no options |
| Total | 2519 | Every input byte accounted for |
The RRSIG metadata includes its fixed 18-byte portion and uncompressed signer name. See RFC 4034. Byte ranges in the record table are inclusive; the downloaded segment data uses a start-inclusive, end-exclusive range.
What remains opaque
For types other than RRSIG, DNSKEY and OPT, the reader counts RDATA without decoding its contents. That keeps the byte total complete while avoiding a false claim of full protocol validation. An unfamiliar record type can still be counted. A malformed record envelope or incomplete declared data causes the whole import to fail rather than producing a partial “passed” result.
Same answer, eleven different bytes.
These two original synthetic DNS messages return the same A-record value, 192.0.2.1, for lab.example.. Neither contains a signature or proves a real lookup. They isolate one accounting choice: writing the answer owner name again, or referring to the question’s name.
45-byte compressed-owner message · 56-byte full-owner message. Paste either hex file into the inspector. Leave the TCP-prefix option off: the files contain DNS messages only.
| Part | Compressed owner | Full owner |
|---|---|---|
| Header | 0–11: 12 bytes | 0–11: 12 bytes |
| Question | 12–28: 17 bytes | 12–28: 17 bytes |
| Answer owner | 29–30: 2 bytes | 29–41: 13 bytes |
| Type, class, TTL, length | 31–40: 10 bytes | 42–51: 10 bytes |
| IPv4 value | 41–44: 4 bytes | 52–55: 4 bytes |
Read the pointer rather than counting the expanded spelling.
The question name begins at byte 12. The compressed answer begins with hex c0 0c: the pointer refers back to that location. The reader may display the expanded name, but only two bytes occupy this position in the packet. In the second file, the name is encoded with its labels and terminator again, consuming thirteen bytes. The difference is 13 − 2 = 11 bytes.
RFC 1035’s compression rules explain the pointer and message-relative offset. Compression is not a cryptographic property and this pair does not contain DNSSEC validation evidence.
Use the pair to detect a bad comparison.
If two real responses have different sizes, first check whether the same questions, records and options are present. Equal displayed answer names do not imply equal encoding. Conversely, a shorter response may omit a record entirely. Compare record counts, types and truncation flags before attributing the whole difference to a signature algorithm.
Both files have one question and one answer, no authority or additional records, and the same 60-second TTL. There is no OPT record, no UDP-size advertisement and no TCP framing to infer. When using the budget control, its number remains your comparison threshold; it is not a field discovered in either fixture. A real resolver’s reply may contain additional records and different compression choices.