DNS SRV Priority Bucket Table
Bucket explicit DNS SRV records by ascending priority with raw weights and total weight evidence; does not implement weighted target selection or availability inference.
Description
Bucket explicit DNS SRV records by ascending priority with raw weights and total weight evidence; does not implement weighted target selection or availability inference.
DNS SRV records organize service candidates by priority and weight. Grouping priorities is useful before a separate selection policy is applied.
When to use this tool
Bucket explicit DNS SRV records by ascending priority with raw weights and total weight evidence; does not implement weighted target selection or availability inference.
- Prepare the supplied recordsJson 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 recordsJson. 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.buckets. Interpret false, null and empty lists using the distinctions below; they can be valid outputs.
Parse recordsJson as priority, weight, port and target objects. The three numeric fields are integers from 0 to 65,535. Group by priority, sort buckets numerically ascending, preserve records within each bucket and sum their weights.1
| Input field | Meaning and representation | Accepted input |
|---|---|---|
| recordsJson | 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": "recordsJson",
"decoded": [
{
"priority": 10,
"weight": 2,
"port": 80,
"target": "a"
},
{
"priority": 10,
"weight": 3,
"port": 80,
"target": "b"
}
]
}
]| Output field | Interpretation |
|---|---|
| result | Object containing the named outputs below. |
| result.buckets | The buckets list in the ordering and representation described above. |
{
"input": {
"recordsJson": "[{\"priority\":10,\"weight\":2,\"port\":80,\"target\":\"a\"},{\"priority\":10,\"weight\":3,\"port\":80,\"target\":\"b\"}]"
},
"output": {
"result": {
"buckets": [
{
"priority": 10,
"records": [
{
"priority": 10,
"weight": 2,
"port": 80,
"target": "a"
},
{
"priority": 10,
"weight": 3,
"port": 80,
"target": "b"
}
],
"weightTotal": 5
}
]
}
}
}Limitations and assumptions
- Targets are strings, without DNS lookup or target validation. This is a bucket table, not randomized SRV selection or a service-reachability test.
- 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 Compression Pointer Offset Formatter
Format an explicit 14-bit packet offset as a DNS compression pointer token; does not verify packet layout or target labels.
- DNS Compression Pointer Offset Parser
Parse exactly one two-byte DNS compression pointer into its 14-bit packet offset; does not dereference the pointer.