DNS Label Byte Budget Audit

Audit supplied DNS label byte lengths and total uncompressed wire-name budget independently; no text character count or IDNA assumption.

Description

Audit supplied DNS label byte lengths and total uncompressed wire-name budget independently; no text character count or IDNA assumption.

DNS label length and total uncompressed name length are separate wire constraints. Auditing them separately can reveal a long label even when the total name fits.

When to use this tool

Audit supplied DNS label byte lengths and total uncompressed wire-name budget independently; no text character count or IDNA assumption.

Prepare the supplied labelsJson 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 labelsJson. 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.labelViolations, result.wireBytes, result.nameFits. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.

Parse labelsJson as nonempty byte arrays without enforcing the usual DNS length constraints. Report each label above 63 bytes, calculate one root byte plus each label's length and length byte, and set nameFits for totals at most 255.^[1]

Input field	Meaning and representation	Accepted input
labelsJson	JSON text, entered as one text field. The decoded structure is illustrated below; it is not a separate file.	Text

For the JSON text fields, the following decoded structures show the example records before they are serialized into input strings. Keep field names, list nesting and value types as shown.

json

[
  {
    "field": "labelsJson",
    "decoded": [
      [
        0,
        1,
        2,
        3,
        4,
        5,
        6,
        7,
        8,
        9,
        10,
        11,
        12,
        13,
        14,
        15,
        16,
        17,
        18,
        19,
        20,
        21,
        22,
        23,
        24,
        25,
        26,
        27,
        28,
        29,
        30,
        31,
        32,
        33,
        34,
        35,
        36,
        37,
        38,
        39,
        40,
        41,
        42,
        43,
        44,
        45,
        46,
        47,
        48,
        49,
        50,
        51,
        52,
        53,
        54,
        55,
        56,
        57,
        58,
        59,
        60,
        61,
        62,
        63
      ]
    ]
  }
]

Output field	Interpretation
result	Object containing the named outputs below.
result.labelViolations	The label violations list in the ordering and representation described above.
result.wireBytes	The wire bytes value under the stated formula or text convention.
result.nameFits	Flag for name fits under the exact condition described above.

json

{
  "input": {
    "labelsJson": "[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63]]"
  },
  "output": {
    "result": {
      "labelViolations": [
        {
          "index": 0,
          "bytes": 64
        }
      ],
      "wireBytes": 66,
      "nameFits": true
    }
  }
}

Limitations and assumptions

nameFits concerns only total length; inspect labelViolations too. Local arrays are limited to 128 entries, and text character counts or IDNA transformations are not inferred.
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

Tool behavior and example: DNS Label Byte Budget Audit — tool.io

Similar or alternative tools

DNS Label ASCII Case Normalizer
Canonicalize DNS ASCII uppercase octets only, leaving non-ASCII bytes unchanged; does not apply Unicode lowercase or IDNA mappings.
DNS Label Canonical Order Compare
Compare DNS names in canonical label order from the root/rightmost label outward using lowercase unsigned octets; no Unicode collation or locale sorting.