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.
Description
Compare DNS names in canonical label order from the root/rightmost label outward using lowercase unsigned octets; no Unicode collation or locale sorting.
Canonical DNS name ordering compares labels from the root outward. This differs from ordinary left-to-right text sorting.
When to use this tool
Compare DNS names in canonical label order from the root/rightmost label outward using lowercase unsigned octets; no Unicode collation or locale sorting.
- Prepare the supplied leftJson, rightJson 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 leftJson, rightJson. 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.order. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Parse leftJson and rightJson as byte-label arrays. Starting at the rightmost label, compare lowercase-ASCII unsigned octets lexicographically; a shorter equal-prefix label sorts first. If every shared label matches, compare label counts. Return -1, 0 or 1.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| leftJson | JSON text, entered as one text field. The decoded structure is illustrated below; it is not a separate file. | Text |
| rightJson | 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.
[
{
"field": "leftJson",
"decoded": [
[
122
],
[
97
]
]
},
{
"field": "rightJson",
"decoded": [
[
97
],
[
98
]
]
}
]| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.order | Comparison result under the exact convention above; -1 means left before right, 0 equal, +1 after. |
{
"input": {
"leftJson": "[[122],[97]]",
"rightJson": "[[97],[98]]"
},
"output": {
"result": {
"order": -1
}
}
}Limitations and assumptions
- No locale collation, Unicode normalization or DNS lookup occurs. Ordering does not validate a DNSSEC signature.
- 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 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 Byte Budget Audit
Audit supplied DNS label byte lengths and total uncompressed wire-name budget independently; no text character count or IDNA assumption.