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

  1. Enter bytes, chunkBytes. Use the exact text syntax, units and index conventions explained below.
  2. Run the tool. If input validation fails, correct the supplied fields before interpreting any result.
  3. 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 fieldMeaning and representationAccepted input
bytesbytes.List of integers from 0 to 255; at most 128 bytes
chunkByteschunk bytes.Integer from 1 to 255 inclusive
Output fieldInterpretation
resultObject containing the named outputs below.
result.chunksThe chunks list in the ordering and representation described above.
json
{
  "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

  1. Tool behavior and example: DNS TXT String Chunk Plan — tool.io

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.

Don't forget to set a bookmark for tool.io!
Privacy | Imprint | Cookies