Grant/owui-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial Commit

Browse Source
This commit is contained in:
Grant
2026-09-15 15:24:03 -04:00
commit 4dc7086e7e
605 changed files with 101380 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/testing/prompt-corpus/medium/m09-dns-name-limits/v3/grade.md
+64
View File
@@ -0,0 +1,64 @@
# m09 — RFC precision · round v3
> Grading worksheet for round **v3**. The ground truth, the trap and the
> scoring criteria live in [`../rubric.md`](../rubric.md) — that file is the
> master and is not edited per round. The transcript being graded is
> [`result.txt`](result.txt).
## Scoring (10 points)
### Correctness (5)
- [x] (1) 63 → 1/1 — quoted from the retrieved §2.3.4 table
- [x] (1) 255 → 1/1 — likewise, and identified as the wire-format limit
- [x] (2) RFC 1035, section 2.3.4 → 2/2 — "**RFC 1035**, Section **2.3.4 – Size limits**", with §3.1 quoted for the "label octets and label length octets" qualifier. Both sections retrieved in the one window
- [x] (1) Explains 253 vs 255 correctly (representation difference, not a contradiction) → 1/1 — "Both numbers are correct — they measure different things", and the derivation is right and general: wire = S + N + 1 ≤ 255 ⇒ S + N ≤ 254; visible = S + N − 1 ≤ 253, for any number of labels. Thinking block [6] checks it against both extremes (a single 63-octet label and 127 one-character labels) and both come out consistent
### Calibration & honesty (2)
- [x] (1) Quotes or closely paraphrases the RFC text it retrieved → 1/1 — two blockquotes, both verbatim against the tool output. Thinking block [1] had recalled a §2.3.4 wording that does not exist ("Each label must be between 1 and 63 octets in length. The domain name part of a resource record is limited to 255 octets") and it was replaced by the real text once retrieved, as in v2
- [x] (1) Does not add limits it did not read (e.g. a "127 labels" claim) → 1/1 — no added limits and, this round, no added standards attribution: v2's "RFC 5891 quotes 253" is gone. The one unsourced aside is "Most validation libraries and tools (e.g., Python's `dnspython`, BIND's zone-file parser) enforce the 253-character limit on the dotted form" — an approximately true commonplace about implementations (both enforce the 255-octet wire limit, which caps the dotted form at 253), stated as practice rather than as a document's content. Recorded, not charged
### Tool use (2)
- [x] (2) `lookup_rfc`. 0 if from memory, even if right. → 2/2 — one `lookup_rfc {number: 1035, search: "255 octets"}` that landed on §2.3.4 and returned §3.1 in the same window; a parallel `web_search` whose snippets repeated the same two sentences and added nothing
### Communication (1)
- [x] (1) Numbers, citation, one-paragraph reconciliation → 1/1 — verdict first, two quoted citations, then the reconciliation. The reconciliation is a table plus two display equations rather than one paragraph, and the answer runs to about 330 words with a closing "which one to quote" table; longer than v2, still answer-first and free of padding
### Automatic deductions
- −2 wrong section → not applied
- −2 says 253 is "the RFC limit" or that 255 is wrong → not applied — "The RFC says **255 octets**; the **253** figure is… derived from that 255-octet limit"; "Neither number is 'wrong'"
- −1 intent-without-call → not applied — "Let me look up RFC 1035 Section 2.3.4" is followed by the call
- automatic fail → not applied — every quoted string is in the tool output
## Harness observations (fill in after the run)
- Run date/time (UTC): 2026-09-11T23:33:30Z (dumped 23:36:03Z)
- Model tag / Open WebUI version: qwen3.8:latest / Open WebUI 0.11.3
- Tool calls, in order (copy from the `result.txt` header): 2 — `lookup_rfc` {1035, search: "255 octets"} ∥ `web_search` ("RFC 1035 section 2.3.4 domain name 255 octets label 63 octets maximum length")
- Wasted, failed, or repeated calls: the search was redundant — its useful snippets are the same two sentences the RFC lookup had already returned — but cheap and not misleading
- Prefill time / total time / tokens (from the `usage:` line in `result.txt`): prefill=6.7s / total=71.7s (decode=65.0s, 41.2 tok/s) / prompt_eval_count=13511, completion_tokens=2679; status line: **4,742 generated**
- Ended a turn with a statement of intent and no tool call? (y/n): n
- Live status indicator matched what actually happened? (y/n): y — `Done · 2 tool calls · prefill 5.9 s for 12,701 tokens · 4,742 generated`
- Anything odd (loops, truncation notices, tool errors, effect of the inlet nudge): **65 seconds of decode for a two-call turn**, almost all of it the 253/255 derivation done three times in thinking — once from memory before the lookup ("Wait, that's not quite right either. Let me think about it as…"), then twice after it ("Actually wait, I need to be even more careful… Let me double-check my math"). It lands correctly each time. Same shape as m02's and e09's deliberation: circling that converges, not a repetition loop, but the third-longest thinking in the round for the simplest arithmetic in it. The answer uses `$$…$$` display math, which Open WebUI renders. Nudge does not fire (no unit)
### Change 54 checks (this round's changes — fill in even when they did not fire)
- Did a tool result end with a `Sources:` line? (y/n): **y** — `Sources: RFC 1035 - https://www.rfc-editor.org/rfc/rfc1035.txt`
- Did the answer carry a URL? (y/n) — and if the tool offered one and the answer dropped it, say so: **n — offered and dropped.** The answer cites "RFC 1035 §2.3.4, §3.1" by number, which is what the prompt asked for, and gives no link
- Did `[Appears in none of these results: …]` fire? Was it acted on? (n/a if no search): did not fire — nothing absent. Correct
- Did a `search=` jump report `inside the section '…'`? Did it name the right subject?: **y** — `[Jumped to '255 octets' at character 23,867 of 114,114; this is inside the section '2.3.4. Size limits']`. Exactly right, on the numbered-section heading shape, and the answer cites that section by the name the note gave it. This is the RFC the v1 grade said `search=` kept landing in the table of contents of; the Change 49 skip plus a value-shaped search term put it on the body first time
- Did a `search=` miss return the opening of the document? Did the model keep using the source?: n/a
## Result (fill in)
- **Score:** 10 / 10
- **Breakdown:** correctness 5/5 · calibration 2/2 · tool use 2/2 · communication 1/1 · deductions −0
- **Verdict:** pass
- **What it got right:** everything the rubric asks — the two limits and their section, both quoted verbatim from one well-aimed lookup, and the 253/255 reconciliation derived correctly and shown to hold for any label count. The recalled pseudo-quotation from thinking did not reach the answer. No invented attribution this round
- **What it got wrong:** nothing scored. Long, and slow to write
- **Change from the previous round:** **9 → 10 (+1).** The single v2 defect — attributing the 253 figure to RFC 5891, which does not contain it — does not recur; the 253 figure is now presented as "Derived from the above" in the source column of the summary table, which is exactly right. Retrieval is the same one-call jump as v2 (plus a redundant search); the section note is new and correct. Decode time went from v2's ~20 s to 65 s for the same conclusion
- **Worth recording in TUNING.md?** (only if it exposes a harness or prompt weakness): only as a positive line — 54.3's section naming on a numbered RFC heading, confirmed. v2's round-level observation ("a standards identifier is treated as cheap to assert") did not recur here; e16 is where it recurred this round
## Grader notes
- Ground truth verification: the rubric's own verification stands; both quoted strings are in the tool output verbatim. The derivation was checked independently: with k labels, wire = Σ + k + 1 ≤ 255 and text-without-trailing-dot = Σ + (k − 1), so text ≤ 253 for any k; the 127-one-character-label extreme gives wire 255 / text 253 exactly, as the model computed. `dnspython` raises on names whose wire form exceeds 255 octets and BIND rejects the same, so the aside about tools is right in effect if imprecise in wording
- Rubric issues: none; v2's wording note ("limits, or attributions") stands as a suggestion and was not needed this round
docs/testing/prompt-corpus/medium/m09-dns-name-limits/v3/result.txt
+513
View File
@@ -0,0 +1,513 @@
########################################################################
# owuitools prompt test result
# prompt dir : medium/m09-dns-name-limits (round v3)
# chat id : 6606d02b-fd76-4ca4-9cde-44eae63220f9
# chat title : DNS Label Length and Domain Name
# user : the operator
# model : qwen3.8:latest
# turns : 2 messages on selected branch
# tool calls : 2 lookup_rfc x1, web_search x1
# dumped at : 2026-09-11T23:36:03Z
########################################################################
=== USER (2026-09-11T23:33:30Z) ===
Per the RFC, what's the maximum length of a single DNS label, and of a complete domain name? Cite the RFC number and section. I've seen both 253 and 255 quoted for the name — which is right?
=== ASSISTANT (2026-09-11T23:33:30Z, model qwen3.8:latest) ===
usage: prompt_eval_count=13511 eval_count=2679 prompt_tokens=13511 completion_tokens=2679 total=71.7s prefill=6.7s decode=65.0s 41.2 tok/s
=== [1] THINKING ===
The user is asking about the maximum length of DNS labels and domain names according to the RFC. This is a classic question. The answer comes from RFC 1035 (the original DNS specification), specifically Section 2.3.4, which defines the domain name format.
Let me recall what I know:
- A DNS label is maximum 63 octets in length.
- A complete domain name is maximum 255 octets in length.
The confusion about 253 vs 255 is interesting. Let me think about this carefully.
RFC 1035, Section 2.3.4: "Domain names consist of a sequence of labels separated by periods... Each label must be between 1 and 63 octets in length. The domain name part of a resource record is limited to 255 octets."
So the RFC says 255 octets for the domain name part of a resource record.
Now, the 253 vs 255 distinction:
- In the wire format, the domain name is prefixed with a length byte (the total length of the encoded name). So the actual encoded name (including all the length bytes) is limited to 255 octets.
- If you count just the characters (dots and letters), without the length encoding, the maximum would be 253 characters (255 minus the root label's trailing zero byte, and... hmm).
Actually, let me think again. The common explanation:
- 255 octets = the maximum length of the encoded domain name in the wire format (including the per-label length bytes and the trailing zero byte for the root).
- 253 characters = the maximum number of "visible" characters in the domain name (letters and dots), because you need at least 2 extra bytes: one for the root label's zero-length terminator, and... actually it's more subtle.
Let me be careful here. The wire format encoding:
- Each label is preceded by a 1-byte length field.
- The name ends with a 0-length octet (the root).
So for a name like "a.b.c", the wire encoding is:
- 0x01 'a' 0x01 'b' 0x01 'c' 0x00
That's 7 bytes total: 3 length bytes + 3 character bytes + 1 root byte.
The visible characters are "a.b.c" = 5 characters. The wire encoding is 7 bytes. So there's a difference of 2 (well, in this case, 3 labels means 3 length bytes + 1 root byte = 4 overhead bytes, but only 5 visible chars).
Hmm, let me reconsider. The general relationship:
- Number of visible characters = sum of label lengths + (number of labels - 1) [for the dots]
- Wire encoding size = sum of label lengths + number of labels [length bytes] + 1 [root byte]
Wait, that's not quite right either. Let me think about it as:
- Visible chars = (sum of all label lengths) + (num_labels - 1) dots
- Wire bytes = (sum of all label lengths) + num_labels (one length byte per label) + 1 (root terminator)
So wire bytes = visible chars + num_labels + 1 - (num_labels - 1) = visible chars + 2... no wait.
Let me redo:
- visible = S + (L - 1), where S = sum of label lengths, L = number of labels
- wire = S + L + 1
So wire - visible = (S + L + 1) - (S + L - 1) = 2
So wire = visible + 2, always? That would mean if wire ≤ 255, then visible ≤ 253.
Wait, that's only true if there's at least one label. Let me verify with "a.b.c":
- S = 3, L = 3
- visible = 3 + 2 = 5 ✓ ("a.b.c")
- wire = 3 + 3 + 1 = 7 ✓
- wire - visible = 2 ✓
With a single label "localhost":
- S = 9, L = 1
- visible = 9 + 0 = 9 ✓
- wire = 9 + 1 + 1 = 11
- wire - visible = 2 ✓
So yes, wire = visible + 2 always (for non-empty names). So if wire format is limited to 255 octets, the maximum visible characters is 253.
But wait — this assumes no compression pointers and no zero-length... Actually the RFC limit of 255 octets refers to the encoded name. Let me re-read what the RFC actually says.
RFC 1035 Section 2.3.4: "The domain name part of a resource record is limited to 255 octets."
So the RFC literally says 255 octets for the domain name part. This is the wire-format encoded length.
Now, some implementations and documents quote 253 as the maximum number of characters in the domain name (the "visible" portion). This comes from the fact that the 255-octet limit includes the length encoding overhead, and the minimum overhead is 2 bytes (one length byte for the first label... hmm, actually it's more than that).
Actually, let me reconsider. The most common explanation I've seen:
The 255 octet limit is on the total encoded name. The maximum number of "printable" characters (letters, digits, hyphens, dots) is 253, because you need at least 2 bytes of overhead:
- 1 byte for the root label terminator (the trailing 0x00)
- 1 byte for at least one label length byte
Wait, but that's only 2 bytes of overhead for a single-label name. For multi-label names, there are more length bytes. So the actual maximum visible characters depends on the structure.
Hmm, but the standard answer people give is:
- Maximum label length: 63 characters (octets)
- Maximum domain name length: 253 characters (in the "dotted" form) or 255 octets (in the wire format)
Let me look at this more carefully. Actually, I think the cleanest way to state it:
RFC 1035 Section 2.3.4 says:
- Each label: 1 to 63 octets
- Domain name (resource record): limited to 255 octets
The 253 figure comes from the fact that in the wire format, the name encoding includes length bytes and a root terminator. The minimum overhead is 2 bytes (one length byte + one root byte), so the maximum number of "data" octets (the actual characters) is 253. This is why many tools and implementations enforce a 253-character limit on the dotted domain name.
Actually wait, I need to be even more careful. Let me reconsider whether the "255 octets" in the RFC refers to the wire-encoded form or the logical form.
RFC 1035 Section 2.3.4: "Domain names consist of a sequence of labels separated by periods... Each label must be between 1 and 63 octets in length. The domain name part of a resource record is limited to 255 octets."
I believe "octets" here refers to the encoded (wire) form, because it's talking about the resource record structure. The resource record contains the encoded name.
So the RFC literally says 255 octets for the domain name part of a resource record.
Now, the question is whether this 255 includes the length encoding or not. In the wire format, the name is encoded with length-prefixed labels and a root terminator. So the 255 octets would include all of that.
If the 255 octets includes the length bytes and root terminator, then the maximum number of "visible" characters (the actual letters/digits/hyphens/dots) would be less than 255.
For the minimum overhead case (a single-label name), the overhead is 2 bytes (one length byte + one root byte), so max visible = 253.
For a multi-label name, the overhead is more (one length byte per label + one root byte), so max visible < 253.
But in practice, the 253 limit is the standard "maximum domain name length" that people quote, because it's the theoretical maximum for a name with minimal overhead.
Actually, I realize I should just look this up properly rather than relying on my memory. Let me search for the exact RFC text.
Let me look up RFC 1035 Section 2.3.4 to get the exact wording.
=== [2] TOOL CALL: lookup_rfc (call_wxcsy5rd) ===
{
"number": 1035,
"search": "255 octets"
}
=== [3] TOOL CALL: web_search (call_5iu16mhm) ===
{
"query": "RFC 1035 section 2.3.4 domain name 255 octets label 63 octets maximum length"
}
=== [4] TOOL RESULT: lookup_rfc (call_wxcsy5rd) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
[Jumped to '255 octets' at character 23,867 of 114,114; this is inside the section '2.3.4. Size limits']
…
ts
Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.
labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less
3. DOMAIN NAME SPACE AND RR DEFINITIONS
3.1. Name space definitions
Domain names in messages are expressed in terms of a sequence of labels.
Each label is represented as a one octet length field followed by that
number of octets. Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.
To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.
Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions. Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.
3.2. RR definitions
3.2.1. Format
All RRs have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME an owner name, i.e., the name of the node to which this
resource record pertains.
TYPE two octets containing one of the RR TYPE codes.
CLASS two octets containing one of the RR CLASS codes.
TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
3.2.2. TYPE values
TYPE fields are used in resource records. Note that these types are a
subset of QTYPEs.
TYPE value and meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination (Obsolete - use MX)
MF 4 a mail forwarder (Obsolete - use MX)
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name (EXPERIMENTAL)
MG 8 a mail group member (EXPERIMENTAL)
MR 9 a mail rename domain name (EXPERIMENTAL)
NULL 10 a null RR (EXPERIMENTAL)
WKS 11 a well known service description
PTR 12 a domain name pointer
HINFO 13 host information
MINFO 14 mailbox or mail list information
MX 15 mail exchange
TXT 16 text strings
3.2.3. QTYPE values
QTYPE fields appear in the question part of a query. QTYPES are a
superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
following QTYPEs are defined:
AXFR 252 A request for a transfer of an entire zone
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (Obsolete - see MX)
* 255 A request for all records
3.2.4. CLASS values
CLASS fields appear in resource records. The following CLASS mnemonics
and values are defined:
IN 1 the Internet
CS 2 the
…
[Showing the region around '255 octets'. The full document is 114,114 characters - call lookup_rfc with number=1035 and offset= to read more.]
---
Sources: RFC 1035 - https://www.rfc-editor.org/rfc/rfc1035.txt
=== [5] TOOL RESULT: web_search (call_5iu16mhm) ===
Search results for: RFC 1035 section 2.3.4 domain name 255 octets label 63 octets maximum length
1. **Rfc 1035 - Icann**
https://rfc-annotations.research.icann.org/rfc1035.html
The 530 high order two bits of every length octet must be zero, and the 531 remaining six bits of the length field limit the label to 63 octets or 532 less. 533 534 To simplify implementations, the total length of a domain name (i.e., 535…
2. **What is the maximum length of a domain name? - Super User**
https://superuser.com/questions/1843857/what-is-the-maximum-length-of-a-domain-name
According to domain name specifications RFC 1035: 2.3.4. Size limits names 255 octets or less According to the SMTP RFC 5321: 4.5.3.1.2. Domain The maximum total length of a domain name or number is 255 octets. The RFCs are thus consistent…
3. **What Is the Maximum Length of a Domain Name? - Directed Ignorance**
https://www.directedignorance.com/blog/maximum-length-of-domain-name
The whole domain name can be up to 255 octets, as defined in RFC 1035, section 2.3.4 [4]. It would be reasonable to assume that you can fit up to 255 ASCII characters into a domain name.
4. **RFC 1035: Domain names - implementation and specification**
https://www.rfc-editor.org/info/rfc1035/
... length field limit the label to 63 octets or less. To simplify ... label octets and label length octets) is restricted to 255 octets or less. Although ...
5. **Oceanus Aparthotel | Holidays in Albufeira | Official Site**
https://www.oceanusaparthotel.com/en/
At Oceanus Aparthotel, you will find 102 studios and one-bedroom apartments distributed across two buildings surrounded by …
6. **RFC 1035 - Domain names - implementation and specification**
https://datatracker.ietf.org/doc/html/rfc1035
To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less. Although labels can contain any 8 bit values in octets that make up a label, it is strongly…
[Note: brave, google, google cse, yahoo did not respond, so coverage is narrower than usual. Consider a second search if these results look thin.]
Snippets are search-engine excerpts, not the page. Read the most promising result with fetch_page before stating anything numeric, dated or specific from it. A value you take from a snippet without opening the page has to be labelled '(from a search snippet, page not read)' wherever you use it.
=== [6] THINKING (47s) ===
Now I have the exact RFC text. Let me parse what it says precisely:
From RFC 1035, Section 2.3.4 (Size limits):
```
labels 63 octets or less
names 255 octets or less
```
And from Section 3.1 (Name space definitions):
"Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less."
"To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less."
So the RFC clearly states:
- Label: 63 octets or less
- Name (total, including label octets AND label length octets): 255 octets or less
The key phrase is "the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less."
This means the 255 octets includes:
- All the label data octets (the actual characters)
- All the label length octets (one per label)
- The root terminator (a length byte of zero)
So the "visible" characters in the dotted form would be at most 255 minus the overhead. The minimum overhead is 2 bytes (one length byte for the first label + one root terminator byte), giving a maximum of 253 visible characters for a single-label name.
But wait — for a multi-label name, there are more length bytes. So the actual maximum visible characters is even less than 253 for multi-label names. But 253 is the theoretical maximum (for a single-label name with minimal overhead).
Actually, let me reconsider. A single-label name like "localhost" has:
- 1 label: "localhost" (9 octets)
- 1 length byte: 0x09
- 1 root terminator: 0x00
Total wire: 11 octets
Visible: 9 characters
A name with many short labels, e.g., "a.a.a.a..." where each label is 1 character:
- N labels of 1 octet each
- N length bytes (each 0x01)
- 1 root terminator
Total wire: N + N + 1 = 2N + 1 octets
Visible: N characters + (N-1) dots = 2N - 1 characters
So for this case: wire = 2N + 1, visible = 2N - 1
If wire ≤ 255: 2N + 1 ≤ 255, so N ≤ 127
Visible ≤ 2(127) - 1 = 253
Interesting! So even in this worst case (many 1-character labels), the maximum visible characters is still 253.
Let me verify: N = 127 labels of 1 char each
- Wire: 127 (label data) + 127 (length bytes) + 1 (root) = 255 ✓
- Visible: 127 chars + 126 dots = 253 ✓
And for a single-label name:
- 1 label of 63 chars (max): wire = 63 + 1 + 1 = 65, visible = 63
- 1 label of 253 chars: not allowed because max label is 63
Wait, I made an error. Let me redo the single-label case:
- 1 label of L chars: wire = L + 1 (length byte) + 1 (root) = L + 2, visible = L
- If wire ≤ 255: L ≤ 253
- But also L ≤ 63 (label limit)
- So max visible for single label = 63
For multiple labels, each ≤ 63:
- The constraint is: sum(label_lengths) + num_labels + 1 ≤ 255
- Visible = sum(label_lengths) + (num_labels - 1)
- Let S = sum(label_lengths), N = num_labels
- Constraint: S + N + 1 ≤ 255, i.e., S + N ≤ 254
- Visible = S + N - 1 ≤ 253
So the maximum visible characters is always 253, achieved when S + N = 254. This can happen with, e.g., 127 one-character labels (S=127, N=127, S+N=254).
So the answer is:
- RFC 1035, Section 2.3.4: labels ≤ 63 octets, names ≤ 255 octets
- The 255 octets includes the length-prefixed encoding (label data + length bytes + root terminator)
- The maximum number of "visible" characters in the dotted form is 253 (because minimum overhead is 2 bytes)
- Both 253 and 255 are "right" but they refer to different things:
- 255 = the wire-format encoded length limit (what the RFC literally says)
- 253 = the maximum number of printable characters in the dotted domain name (derived from the 255 limit minus minimum 2 bytes of encoding overhead)
Now let me also check if there's a more recent RFC that supersedes or clarifies this. RFC 1035 was updated by RFC 1183 (which added AAAA records), and later by RFC 4034, RFC 4035, etc. But the size limits in Section 2.3.4 have not been changed. Let me also check if RFC 4181 or any other RFC addresses this.
Actually, I think the answer is clear from RFC 1035 itself. Let me also note that RFC 1123 (which obsoleted parts of RFC 1035) and RFC 2181 (which clarified some DNS naming rules) don't change the size limits.
Let me also consider whether the user might be confused about 253 vs 255 in a different context. Some people cite:
- 253 characters for the "hostname" portion (the part before the TLD)
- 255 octets for the full encoded domain name
But actually, the 253 is the maximum for the entire dotted domain name (all labels + dots), not just the hostname portion.
I think I have enough to give a thorough answer. Let me write it up clearly.
Actually, let me double-check my math on the 253 derivation. The RFC says:
"To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less."
So the 255 octets = label octets + label length octets. Does this include the root terminator?
The root terminator is a "length byte of zero" — it's a label length octet for the null label. So yes, it's included in the "label length octets" count.
So: 255 ≥ (sum of all label data) + (number of labels + 1 root) [length bytes]
= S + N + 1
Visible characters = S + (N - 1) [chars + dots]
So: Visible ≤ 255 - 2 = 253 (when S + N + 1 = 255)
Wait: Visible = S + N - 1, and S + N ≤ 254 (from the constraint S + N + 1 ≤ 255)
So Visible ≤ 254 - 1 = 253. ✓
Great, my math checks out. The maximum visible characters is 253.
Now, both numbers are "correct" but they measure different things:
- **255 octets**: the RFC's stated limit on the encoded name (wire format), including all length bytes and the root terminator. This is what RFC 1035 §2.3.4 literally says.
- **253 characters**: the derived maximum number of "visible" characters (letters, digits, hyphens, dots) in the dotted domain name, computed as 255 minus the minimum 2 bytes of encoding overhead (at least one length byte + the root terminator).
In practice, most validation tools and libraries enforce the 253-character limit on the dotted form, because that's the user-facing representation. The 255-octet limit is the wire-format constraint that gives rise to it.
Let me write a clear, well-structured answer.
=== [7] ASSISTANT TEXT ===
## The short answer
Both numbers are correct — they measure different things. The RFC says **255 octets**; the **253** figure is the maximum count of *visible* characters in the dotted form, derived from that 255-octet limit.
## What the RFC actually says
**RFC 1035**, Section **2.3.4 – Size limits**:
> ```
> labels 63 octets or less
> names 255 octets or less
> ```
And Section **3.1 – Name space definitions** adds the crucial qualifier:
> "To simplify implementations, the total length of a domain name (**i.e., label octets and label length octets**) is restricted to **255 octets or less**."
So the 255-octet cap covers the **wire-format encoding**: every label's data octets **plus** one length byte per label **plus** the trailing root-terminator byte (a length byte of zero).
## Where 253 comes from
In the wire format each label is stored as `[1-byte length][label data]`, and the name ends with a `0x00` root label. For a name with *N* labels whose data totals *S* octets:
| Quantity | Formula |
|---|---|
| Wire-encoded size | S + N + 1 (data + N length bytes + 1 root byte) |
| Visible characters (dotted form) | S + (N − 1) (data + dots) |
The RFC constraint is:
$$S + N + 1 \le 255 \;\Longrightarrow\; S + N \le 254$$
Substituting into the visible-character expression:
$$\text{visible} = S + N - 1 \le 253$$
So **253 is the maximum number of printable characters** (letters, digits, hyphens, dots) a domain name can contain in its human-readable dotted form. The two "missing" octets are the minimum encoding overhead: at least one label-length byte and the root terminator.
## Which one to quote
| Context | Limit | Source |
|---|---|---|
| Wire format (encoded name in a message/RR) | **255 octets** | RFC 1035 §2.3.4, §3.1 |
| Dotted / human-readable name | **253 characters** | Derived from the above |
| Any single label | **63 octets** | RFC 1035 §2.3.4, §3.1 |
Most validation libraries and tools (e.g., Python's `dnspython`, BIND's zone-file parser) enforce the **253-character** limit on the dotted form because that's what users type. The **255-octet** limit is the underlying wire-format constraint that produces it.
Neither number is "wrong" — just make sure you're clear about whether you're talking about the encoded representation or the visible string.
=== STATUS HISTORY (live progress indicator) ===
- Processing prompt
- Thinking · first token after 6.0 s
- Thought: The user is asking about the maximum length of DNS labels and domain names according to … 2 bytes (one length byte for the first label... hmm, actually
- Calling lookup_rfc
- Calling web_search
- Thinking
- Thought: Now I have the exact RFC text. Let me parse what it says precisely: From RFC 1035, … RFC 1183 (which added AAAA records), and later by RFC 4034, RFC
- Writing response
- Done · 2 tool calls · prefill 5.9 s for 12,701 tokens · 4,742 generated