DNS TXT String Chunk Plan
Plan explicit DNS TXT octet chunks under a supplied 1–255 byte per-string limit; empty data becomes one empty TXT string, no Unicode byte splitting inference.
Description
Plan explicit DNS TXT octet chunks under a supplied 1–255 byte per-string limit; empty data becomes one empty TXT string, no Unicode byte splitting inference.
A byte payload can be divided into consecutive TXT-sized components without interpreting its character encoding. This planner preserves every supplied octet.
When to use this tool
Plan explicit DNS TXT octet chunks under a supplied 1–255 byte per-string limit; empty data becomes one empty TXT string, no Unicode byte splitting inference.
- Prepare the supplied bytes, chunkBytes fields for this operation.
- Compare the complete example with the representation used by your own input before carrying the result into another step.
How to use the tool and how it works
- Enter bytes, chunkBytes. Use the exact text syntax, units and index conventions explained below.
- Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
- Read result.chunks. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
chunkBytes is an integer from 1 to 255. Slice the byte list at successive multiples of that size; an empty payload returns one empty component.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| bytes | bytes. | List of integers from 0 to 255; at most 128 bytes |
| chunkBytes | chunk bytes. | Integer from 1 to 255 inclusive |
| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.chunks | The chunks list in the ordering and representation described above. |
{
"input": {
"bytes": [
1,
2,
3,
4,
5
],
"chunkBytes": 2
},
"output": {
"result": {
"chunks": [
[
1,
2
],
[
3,
4
],
[
5
]
]
}
}
} Limitations and assumptions
- This is a chunk plan, without length prefixes or a DNS record. It does not avoid splitting a multibyte encoded character or validate application semantics.
- All declared input fields are required and unexpected top-level fields are rejected. Numbers must be finite; lists are limited to 128 entries and ordinary text fields to 8,192 UTF-16 code units, with tighter limits where stated.
- JSON text inputs must parse within bounded nesting and size limits. Numeric outputs outside the safe finite range are rejected; large exact integer results use decimal strings. Indexes and half-open spans are zero-based unless a rank is explicitly described as one-based.
Alternative or Complementary methods
Use a packet-aware DNS parser or resolver when the task requires compression-chain validation, live records or complete resource-record semantics. Keep byte labels, presentation text and network packets distinct.
References
Similar or alternative tools
- DNS TXT String Wire Formatter
Format a nonempty DNS TXT character-string list as length-prefixed octets without a terminator; total output is bounded to 128 bytes and strings are not text-decoded.
- DNS TXT String Wire Parser
Parse a complete nonempty DNS TXT wire character-string list, retaining empty strings and rejecting incomplete trailing payload; no text encoding assumptions.