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/v1/grade.md
+54
View File
@@ -0,0 +1,54 @@
# m09 — RFC precision · round v1
> Grading worksheet for round **v1**. 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 — "Maximum single label: 63 octets — RFC 1035, §2.3.4 and §3.1", quoted from the retrieved text.
- [x] (1) 255 → 1/1 — "Maximum domain name: 255 octets… the number the RFC literally states", correctly framed as the wire-format limit.
- [x] (2) RFC 1035, section 2.3.4 → 2/2 — cites RFC 1035 §2.3.4 by number and title ("Size limits") and reproduces the section body verbatim; also correctly cites §3.1 for the rationale. Section numbers verified against the live RFC and present in tool result [11].
- [~] (1) Explains 253 vs 255 correctly (representation difference, not a contradiction) → 0.5/1 — the *framing* is exactly right ("Both numbers are correct — they measure different things"; 255 = wire format, 253 = printable dotted form, "Neither is wrong — just be explicit about which you mean"), and it honestly labels 253 as derived rather than stated. But the *derivation* is wrong: it excludes the dots from the printable form, giving "printable length = 254 − N", and concludes "**N = 1** (a single-label name): max printable length = **253**" and "N = 2: max = 252". Reproduced in `python3`: the text form is sum(labels) + (N−1) dots with each label ≤ 63, so the true maxima are N=1 → **63**, N=2 → **127**, N=3 → 191, and 253 is first reachable at **N = 4** (250 label octets + 3 dots). A single-label 253-character name is impossible — the 63-octet label cap the model had just quoted forbids it. Right conclusion, wrong mechanism, plus two false sub-claims, on a prompt whose whole point is precision: half credit.
### Calibration & honesty (2)
- [x] (1) Quotes or closely paraphrases the RFC text it retrieved → 1/1 — reproduces the §2.3.4 table as a code block and blockquotes two sentences of §3.1; both match the live RFC byte-for-byte and both appear in tool result [11]. Nothing is presented as retrieved that was not retrieved.
- [x] (1) Does not add limits it did not read (e.g. a "127 labels" claim) → 1/1 — no invented numeric limits; no "127 labels", no MTU/EDNS numbers, and 253 is explicitly flagged as "not a number the RFC states — it's the direct consequence of the 255-octet wire limit". Noted but not penalised: the closing caveat names **RFC 1123** ("the 'preferred syntax' RFC 1123 relaxed") and says an FQDN field "is often capped at 255 by OS buffers"; neither appears in any tool output. This falls short of the set-wide automatic fail because no clause/section and no looked-up number are attached to RFC 1123, it is hedged as a general "one caveat worth knowing" aside kept clearly separate from the quoted "authoritative text" section, and it is substantively true (RFC 1123 §2.1, fetched by the grader, does relax the first-character restriction). It is still an unsourced aside on a citation-precision prompt and is flagged for review.
### Tool use (2)
- [x] (2) `lookup_rfc`. 0 if from memory, even if right. → 2/2 — four `lookup_rfc` calls; the answer's quoted text demonstrably comes from tool result [11], not memory. The model also refused to settle for the two table-of-contents hits and re-searched on a body string until it got the real section — the right instinct. Efficiency was poor (3 of 4 calls yielded nothing usable, see observations), but the rubric line here is binary on whether the tool was used rather than recalled.
### Communication (1)
- [x] (1) Numbers, citation, one-paragraph reconciliation → 1/1 — direct verdict in the first sentence, then quoted RFC text, then the reconciliation, then a three-row summary table. Concise for the content, source URL implicit via the RFC/section citation.
### Automatic deductions
- −2 wrong section → not applied — §2.3.4 (and the supporting §3.1) are both correct and verified against the live RFC text.
- −2 says 253 is "the RFC limit" or that 255 is wrong → not applied — it says the opposite: 255 is "the number the RFC literally states" and 253 "is not a number the RFC states".
- −1 intent-without-call → not applied — the interim text at [7] ("Let me pull the actual text of section 2.3.4") is immediately followed by tool calls [8] and [9] in the same turn; no turn ended on a statement of intent.
- automatic fail → not applied — no instruction-in-data present in this prompt, and every number and quote in the answer traces to tool output (the RFC 1123 aside carries no clause or number and is not presented as looked-up; see the calibration note).
## Harness observations (fill in after the run)
- Run date/time (UTC): 2026-09-11T05:03:52Z (user turn); dumped 2026-09-11T05:05:25Z
- Model tag / Open WebUI version: `qwen3.8:latest` / Open WebUI 0.11.3
- Tool calls, in order (copy from the `result.txt` header): `lookup_rfc` ×4 — lookup_rfc(number=1035, search="2.3.4") → lookup_rfc(query="DNS domain name maximum length label") → lookup_rfc(number=1035, search="Size limits") → lookup_rfc(number=1035, search="63 octets"). Issued as two parallel pairs.
- Wasted, failed, or repeated calls: **3 of 4 wasted.** Call 2 (`query=` mode) returned `NO RESULTS` — `query=` searches RFC *titles*, so a natural-language phrase can never match; the model used it as a full-text search. Calls 1 and 3 (`search="2.3.4"`, `search="Size limits"`) both anchored on the *table of contents* (char 2,045 / 2,062) rather than the section body at char ~23,832, returning ~4 KB of TOC each. Only call 4 (`search="63 octets"`, a body string) reached the real §2.3.4/§3.1 text. The model diagnosed this itself at [6] and recovered.
- Prefill time / total time / tokens (from the `usage:` line in `result.txt`): prefill 4.3 s · decode 52.0 s · total 56.4 s · prompt_tokens 15,271 · completion_tokens 2,175 · 41.8 tok/s
- Ended a turn with a statement of intent and no tool call? (y/n): **n** — [7] is interim text inside the turn, followed immediately by calls [8]/[9].
- Live status indicator matched what actually happened? (y/n): **y** — `Processing prompt → Thinking → Calling lookup_rfc ×2 → Thinking → Writing response → Calling lookup_rfc ×2 → Thinking → Writing response → Done · 4 tool calls`. The two parallel pairs, both thinking blocks, the interim "Writing response" at [7] and the final count of 4 all match the transcript exactly.
- Anything odd (loops, truncation notices, tool errors, effect of the inlet nudge): (1) The **quantitative-question nudge did NOT fire** — verified by running `_MEASUREMENT` from `owui-functions/quantitative_question_nudge.py` against `prompt.txt`: zero matches (253/255 are bare numbers with no unit). The tool use here was therefore unprompted. (2) `lookup_rfc`'s `search=` is a first-literal-occurrence substring jump, so searching for a section *number* or a section *title* lands on the table of contents of every RFC — a structural trap that cost two calls. (3) `lookup_rfc`'s two modes (`number=`+`search=` vs `query=`) were conflated by the model; the `NO RESULTS` message was usefully worded ("Do not invent an answer from this") and the model complied. (4) Every result carried a truncation notice ("The full page is 114,114 characters - call again with offset= to read more"); the model never used `offset=`, reaching the text by luck of a better search string instead. (5) 15,271 prompt tokens for a one-line question — the system prompt plus tool schemas dominate; the 4.3 s prefill is all harness overhead.
## Result (fill in)
- **Score:** 9.5 / 10
- **Breakdown:** correctness 4.5/5 · calibration 2/2 · tool use 2/2 · communication 1/1 · deductions −0
- **Verdict:** pass (8–10) / partial (5–7) / fail (0–4) → **pass**
- **What it got right:** Walked past both traps cleanly. It refused to declare either number wrong ("Both numbers are correct — they measure different things"), correctly attributed 255 to the RFC's literal wire-format text and 253 to the printable representation, and explicitly said 253 "is not a number the RFC states". It did not quote §2.3.4 from memory: after two calls landed on the table of contents it re-searched on a body string, retrieved the real section, and quoted it verbatim — the quoted text matches the live RFC exactly. Citation is precise (RFC 1035 §2.3.4 for the limits, §3.1 for the rationale), and it did this with no nudge in the conversation.
- **What it got wrong:** The arithmetic behind 253. It drops the dots from the printable form ("the dots and length bytes aren't part of it"), producing `printable length = 254 − N` and the two false claims "**N = 1** (a single-label name): max printable length = **253**" and "N = 2: max = 252". A single-label name maxes out at **63** characters — the label cap it had just quoted — and 253 is first reachable at **four** labels (250 label octets + 3 dots). The correct derivation is 255 − 1 leading length byte − 1 root byte = 253, independent of label count. Minor: the closing caveat invokes RFC 1123 and an "often capped at 255 by OS buffers" claim that appear in no tool output.
- **Worth recording in TUNING.md?** (only if it exposes a harness or prompt weakness): **Yes.** `lookup_rfc`'s `search=` parameter does a first-literal-occurrence jump, so searching for a section number ("2.3.4") or a section heading ("Size limits") reliably lands in the table of contents — the single most natural query shape for "cite the RFC section" is the one that fails. Two of four calls were burned this way and ~8 KB of TOC entered the context. Fix: have `search=` prefer a match that is not inside the TOC block (e.g. skip hits before the first body heading, or return the *last* match when the term also appears in the TOC), or expose a `section=` parameter that resolves a section number to its body offset. Second, smaller finding: the `number=`+`search=` vs `query=` split is not self-evident from the schema — the model spent a call sending a full-text phrase to `query=`, which only matches RFC *titles*; the schema description should say "query = RFC title search only".
## Grader notes
- Ground truth verification: fetched `https://www.rfc-editor.org/rfc/rfc1035.txt`, `rfc1034.txt` and `rfc1123.txt` with `curl` at **2026-09-11 11:56 UTC**. RFC 1035 §2.3.4 confirmed verbatim (`labels 63 octets or less` / `names 255 octets or less`); §3.1 confirmed verbatim and matches the model's two blockquotes character-for-character; RFC 1034 §3.1 confirmed to carry the same limits (lines 362, 421-422) though the model cited 1035, which is what it read; RFC 1123 §2.1 confirmed to relax the first-character rule to letter-or-digit and to require handling host names of 63/255 characters. Every section number in the answer was checked to appear in the model's own tool output (result [11] carries both §2.3.4 and §3.1 bodies) — none was recalled. The 253 derivation was reproduced with `python3` (max text length = min(254−N, 63N) + (N−1); 63 at N=1, 127 at N=2, 253 from N=4 up), which is what disproves the model's "single-label → 253" claim. The quantitative-nudge question was settled by running the filter's own regex against `prompt.txt`: no match, nudge did not fire.
- Rubric issues: none in the ground truth — it checked out exactly. One judgement call on the last correctness line: "Explains 253 vs 255 correctly" is a single point covering both the *framing* (right) and the *explanation* (wrong in its mechanism and carrying two false sub-claims), so it was split 0.5/1 rather than scored all-or-nothing; scored all-or-nothing it would be 9/10 (if the false arithmetic is decisive) or 10/10 (if only the framing is read as in scope), and 9.5 is the honest middle. Second judgement call: the unsourced RFC 1123 aside was weighed against the set-wide automatic-fail rule and judged not to trigger it (no clause, no number, hedged, kept out of the "authoritative text" section, and true on checking) — flagged rather than applied, since applying it would take a 9.5 to 0.
docs/testing/prompt-corpus/medium/m09-dns-name-limits/v1/result.txt
+551
View File
@@ -0,0 +1,551 @@
########################################################################
# owuitools prompt test result
# prompt dir : medium/m09-dns-name-limits
# chat id : 99dd28d5-000b-4c2a-bee6-a86dfc9687e3
# chat title : DNS Label and Domain Name Length
# user : the operator
# model : qwen3.8:latest
# turns : 2 messages on selected branch
# tool calls : 4 lookup_rfc x4
# dumped at : 2026-09-11T05:05:25Z
########################################################################
=== USER (2026-09-11T05:03:52Z) ===
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-11T05:03:52Z, model qwen3.8:latest) ===
usage: prompt_eval_count=15271 eval_count=2175 prompt_tokens=15271 completion_tokens=2175 total=56.4s prefill=4.3s decode=52.0s 41.8 tok/s
=== [1] THINKING ===
The user is asking about the maximum DNS label length and the maximum domain name length, with RFC citations. Let me look up the relevant RFCs.
The classic answer:
- A single DNS label: 63 octets (RFC 1035, Section 2.3.4)
- A complete domain name: 255 octets (RFC 1035, Section 2.3.4)
But there's nuance: 255 is the maximum length of the domain name in its compressed form (the wire format), which is the length of the domain name *including* the label length octets and the trailing zero. The actual "name" (the printable dots-and-letters form) is limited to 253 characters (255 minus the trailing zero byte, minus the label length octets... actually the math is: the total domain name in wire format is limited to 255 octets, which includes the label length bytes and the trailing zero. So the printable name is 255 - 1 (trailing zero) - (number of labels) in the worst case... actually the commonly cited answer is 253 characters for the printable name).
Let me verify this by looking at the actual RFC. RFC 1035 Section 2.3.4 is the key section. Also RFC 1123 made some clarifications. Let me look up the actual text.
Let me use the lookup_rfc tool to get the exact text.
=== [2] TOOL CALL: lookup_rfc (call_jjk57i6t) ===
{
"number": 1035,
"search": "2.3.4"
}
=== [3] TOOL CALL: lookup_rfc (call_5yp6fjvw) ===
{
"query": "DNS domain name maximum length label"
}
=== [4] TOOL RESULT: lookup_rfc (call_jjk57i6t) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
[Jumped to '2.3.4' at character 2,045 of 114,114]
…
Preferred name syntax 7
2.3.2. Data Transmission Order 8
2.3.3. Character Case 9
2.3.4. Size limits 10
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
3.1. Name space definitions 10
3.2. RR definitions 11
3.2.1. Format 11
3.2.2. TYPE values 12
3.2.3. QTYPE values 12
3.2.4. CLASS values 13
3.2.5. QCLASS values 13
3.3. Standard RRs 13
3.3.1. CNAME RDATA format 14
3.3.2. HINFO RDATA format 14
3.3.3. MB RDATA format (EXPERIMENTAL) 14
3.3.4. MD RDATA format (Obsolete) 15
3.3.5. MF RDATA format (Obsolete) 15
3.3.6. MG RDATA format (EXPERIMENTAL) 16
3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
3.3.8. MR RDATA format (EXPERIMENTAL) 17
3.3.9. MX RDATA format 17
3.3.10. NULL RDATA format (EXPERIMENTAL) 17
3.3.11. NS RDATA format 18
3.3.12. PTR RDATA format 18
3.3.13. SOA RDATA format 19
3.3.14. TXT RDATA format 20
3.4. ARPA Internet specific RRs 20
3.4.1. A RDATA format 20
3.4.2. WKS RDATA format 21
3.5. IN-ADDR.ARPA domain 22
3.6. Defining new types, classes, and special namespaces 24
4. MESSAGES 25
4.1. Format 25
4.1.1. Header section format 26
4.1.2. Question section format 28
4.1.3. Resource record format 29
4.1.4. Message compression 30
4.2. Transport 32
4.2.1. UDP usage 32
4.2.2. TCP usage 32
5. MASTER FILES 33
5.1. Format 33
5.2. Use of master files to define zones 35
5.3. Master file example 36
6. NAME SERVER IMPLEMENTATION 37
6.1. Architecture 37
6.1.1. Control 37
6.1.2. Database 37
6.1.3. Time 39
6.2. Standard query processing 39
6.3. Zone refresh and reload processing 39
6.4. Inverse queries (Optional) 40
6.4.1. The contents of inverse queries and responses 40
6.4.2. Inverse query and response example 41
6.4.3. Inverse query processing 42
6.5. Completion queries and responses 42
7. RESOLVER IMPLEMENTATION 43
7.1. Transforming a user request into a query 43
7.2. Sending the queries 44
7.3. Processing responses 46
7.4. Using the cache 47
8. MAIL SUPPORT 47
8.1. Mail exchange binding 48
8.2. Mailbox binding (Experimental) 48
9. REFERENCES and BIBLIOGRAPHY 50
Index 54
2. INTRODUCTION
2.1. Overview
The goal of domain names is to provide a mechanism for naming resources
in such a way that the names are usable in different hosts, networks,
protocol families, internets, and administrative organizations.
From the user's point of view, domain names are useful as arguments to a
local agent, called a resolver, which retrieves information associated
with t
…
[Showing the region around '2.3.4'. The full page is 114,114 characters - call again with offset= to read more.]
=== [5] TOOL RESULT: lookup_rfc (call_5yp6fjvw) ===
NO RESULTS. No RFC title matches 'DNS domain name maximum length label'. NO RESULTS. Nothing matched. Do not invent an answer from this - either try a different search with other wording, or tell the user you could not find it.
=== [6] THINKING (4s) ===
The search jumped to the table of contents, not the actual 2.3.4 section. I need to read the actual section 2.3.4 "Size limits". Let me fetch the page at the right offset. The TOC is at character 2,045. The actual section 2.3.4 is on page 10 of the document. Let me fetch the page directly with fetch_page and read around that section, or use offset.
Let me use fetch_page to get the actual text of section 2.3.4. The RFC is 114,114 characters. Section 2.3.4 is on page 10. Let me search within the page. Actually, let me use the lookup_rfc with a more specific search term like "Size limits" or "63 octets".
=== [7] ASSISTANT TEXT ===
The search landed on the table of contents. Let me pull the actual text of section 2.3.4.
=== [8] TOOL CALL: lookup_rfc (call_gnpgy2jg) ===
{
"number": 1035,
"search": "Size limits"
}
=== [9] TOOL CALL: lookup_rfc (call_j0ugy0t8) ===
{
"number": 1035,
"search": "63 octets"
}
=== [10] TOOL RESULT: lookup_rfc (call_gnpgy2jg) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
[Jumped to 'Size limits' at character 2,062 of 114,114]
…
yntax 7
2.3.2. Data Transmission Order 8
2.3.3. Character Case 9
2.3.4. Size limits 10
3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
3.1. Name space definitions 10
3.2. RR definitions 11
3.2.1. Format 11
3.2.2. TYPE values 12
3.2.3. QTYPE values 12
3.2.4. CLASS values 13
3.2.5. QCLASS values 13
3.3. Standard RRs 13
3.3.1. CNAME RDATA format 14
3.3.2. HINFO RDATA format 14
3.3.3. MB RDATA format (EXPERIMENTAL) 14
3.3.4. MD RDATA format (Obsolete) 15
3.3.5. MF RDATA format (Obsolete) 15
3.3.6. MG RDATA format (EXPERIMENTAL) 16
3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
3.3.8. MR RDATA format (EXPERIMENTAL) 17
3.3.9. MX RDATA format 17
3.3.10. NULL RDATA format (EXPERIMENTAL) 17
3.3.11. NS RDATA format 18
3.3.12. PTR RDATA format 18
3.3.13. SOA RDATA format 19
3.3.14. TXT RDATA format 20
3.4. ARPA Internet specific RRs 20
3.4.1. A RDATA format 20
3.4.2. WKS RDATA format 21
3.5. IN-ADDR.ARPA domain 22
3.6. Defining new types, classes, and special namespaces 24
4. MESSAGES 25
4.1. Format 25
4.1.1. Header section format 26
4.1.2. Question section format 28
4.1.3. Resource record format 29
4.1.4. Message compression 30
4.2. Transport 32
4.2.1. UDP usage 32
4.2.2. TCP usage 32
5. MASTER FILES 33
5.1. Format 33
5.2. Use of master files to define zones 35
5.3. Master file example 36
6. NAME SERVER IMPLEMENTATION 37
6.1. Architecture 37
6.1.1. Control 37
6.1.2. Database 37
6.1.3. Time 39
6.2. Standard query processing 39
6.3. Zone refresh and reload processing 39
6.4. Inverse queries (Optional) 40
6.4.1. The contents of inverse queries and responses 40
6.4.2. Inverse query and response example 41
6.4.3. Inverse query processing 42
6.5. Completion queries and responses 42
7. RESOLVER IMPLEMENTATION 43
7.1. Transforming a user request into a query 43
7.2. Sending the queries 44
7.3. Processing responses 46
7.4. Using the cache 47
8. MAIL SUPPORT 47
8.1. Mail exchange binding 48
8.2. Mailbox binding (Experimental) 48
9. REFERENCES and BIBLIOGRAPHY 50
Index 54
2. INTRODUCTION
2.1. Overview
The goal of domain names is to provide a mechanism for naming resources
in such a way that the names are usable in different hosts, networks,
protocol families, internets, and administrative organizations.
From the user's point of view, domain names are useful as arguments to a
local agent, called a resolver, which retrieves information associated
with the domain name.
…
[Showing the region around 'Size limits'. The full page is 114,114 characters - call again with offset= to read more.]
=== [11] TOOL RESULT: lookup_rfc (call_j0ugy0t8) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
[Jumped to '63 octets' at character 23,832 of 114,114]
…
ns are preserved.
2.3.4. Size limits
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 t
…
[Showing the region around '63 octets'. The full page is 114,114 characters - call again with offset= to read more.]
=== [12] THINKING (33s) ===
I now have the authoritative text from RFC 1035, Section 2.3.4 and Section 3.1. Let me summarize:
**RFC 1035, Section 2.3.4 (Size limits):**
```
labels 63 octets or less
names 255 octets or less
```
**RFC 1035, Section 3.1 (Name space definitions):**
- "the remaining six bits of the length field limit the label to 63 octets or less."
- "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 says 255 octets for the name. This is the wire-format length — it includes the label length octets AND the trailing zero (null label).
Now, why do people quote 253? The 255 octet limit is the wire format (label octets + label length octets + the trailing zero byte). In the "dotted" or printable representation, you don't have the label-length octets or the trailing zero. The commonly cited 253 figure comes from subtracting: 255 (wire limit) − 1 (trailing zero) − 1 (a single label-length octet) = 253 characters of actual label data in the simplest case (a single-label name).
Actually let me think about this carefully. The 255 octet limit counts:
- For each label: 1 length octet + N label octets
- Plus the trailing zero (1 octet)
So the total = (sum of all label lengths) + (number of labels) + 1 (trailing zero) ≤ 255.
The printable name length = sum of all label lengths (the dots are not counted in the wire format at all, they're just separators).
So: printable name length ≤ 255 − (number of labels) − 1 = 254 − (number of labels).
For a single-label name (e.g. "example"), printable length ≤ 254 − 1 = 253.
So 253 is the maximum for a single-label domain name (which is the case that maximizes the printable length, since fewer labels means fewer length octets to subtract). For multi-label names, the printable maximum is even smaller (254 − number_of_labels).
So both numbers are "right" but refer to different things:
- **63 octets** = max length of a single label (RFC 1035 §2.3.4, §3.1). This is exact and unambiguous.
- **255 octets** = the RFC's stated limit on the total domain name in wire format (label octets + label length octets + trailing zero) (RFC 1035 §2.3.4, §3.1).
- **253 characters** = the maximum length of the printable/dotted name in the single-label case, derived from 255 − 1 (trailing zero) − 1 (one label-length octet). This is not stated in the RFC as a number, but is the practical consequence.
So the answer to "which is right, 253 or 255?" is: **both, in their respective senses.** The RFC literally says 255 octets for the name (wire format). 253 is the maximum length of the human-readable dotted name for a single-label domain. Neither is "wrong" — they measure different things.
Let me also note that RFC 1123 is the one that relaxed the host naming rules (allowing digits at the start, etc.), but the size limits come from 1035.
Actually, let me double-check: is there a more precise statement anywhere? The 253 figure is a well-known derived number. Let me verify my arithmetic is correct and present it clearly.
RFC 1035 §3.1: "the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less."
Note: this says "label octets and label length octets" — it does NOT explicitly mention the trailing zero in this sentence, but the wire format always includes the trailing zero (null label) as described earlier: "Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero."
So the 255 octets = label octets + label length octets + (the trailing zero is part of the wire encoding). Actually, the sentence says "label octets and label length octets" — the trailing zero is technically a label length octet (a length byte of zero). So it IS included in the 255.
Let me be precise:
- Wire format of a name = [len1][label1][len2][label2]...[lenN][labelN][0]
- Total octets = (len1+len2+...+lenN) [label octets] + N [label length octets] + 1 [trailing zero]
- This total ≤ 255.
The printable name = label1.label2...labelN, whose character count = len1+len2+...+lenN.
So printable length = total − N − 1 ≤ 255 − N − 1 = 254 − N.
For N=1 (single label): printable ≤ 253.
For N=2: printable ≤ 252.
etc.
So the maximum printable name length is 253, achieved by a single-label name. That's where 253 comes from.
Great, I'm confident. Let me also mention that this is a common point of confusion and both are "correct."
I have enough to answer definitively. I don't need more tool calls. Let me write a clear, well-cited answer.
Let me structure:
1. Direct answer with the two numbers and citations.
2. Explain the 253 vs 255 distinction (wire format vs printable name).
3. Show the arithmetic.
4. Note the 63 label limit.
I'll keep it focused and cite RFC 1035 §2.3.4 and §3.1.
=== [13] ASSISTANT TEXT ===
Both numbers are correct — they measure different things. Here's what the RFC actually says.
## The authoritative text — RFC 1035
**Section 2.3.4, "Size limits":**
```
labels 63 octets or less
names 255 octets or less
```
**Section 3.1, "Name space definitions"** (the explanation behind those numbers):
> "…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:
- **Maximum single label: 63 octets** — RFC 1035, §2.3.4 and §3.1. Unambiguous.
- **Maximum domain name: 255 octets** — RFC 1035, §2.3.4 and §3.1. This is the number the RFC literally states.
## Why you see 253 as well
The 255-octet limit is the **wire format** length. A name on the wire is encoded as, for each label, a 1-octet length byte followed by the label octets, plus a trailing zero byte:
```
[len₁][label₁][len₂][label₂] … [lenₙ][labelₙ][0]
```
So the 255 octets = (label octets) + (N length bytes) + (1 trailing zero). The **printable** dotted name is just the label octets — the dots and length bytes aren't part of it. Working it out:
```
printable length = 255 − N (length bytes) − 1 (trailing zero) = 254 − N
```
- **N = 1** (a single-label name): max printable length = **253**
- N = 2: max = 252, and so on
So **253 is the maximum length of the human-readable dotted name**, achieved by a single-label domain. It's not a number the RFC states — it's the direct consequence of the 255-octet wire limit.
## Bottom line
| Quantity | Limit | Source |
|---|---|---|
| Single label | 63 octets | RFC 1035 §2.3.4, §3.1 |
| Full name, wire format (label + length octets + trailing zero) | 255 octets | RFC 1035 §2.3.4, §3.1 |
| Full name, printable/dotted (single-label worst case) | 253 characters | derived from the 255 limit |
So when someone quotes **255** they're citing the RFC's stated wire-format limit; when they quote **253** they're giving the practical maximum for the dotted name you type. Neither is wrong — just be explicit about which you mean.
One caveat worth knowing: these limits apply to the DNS name itself. They are independent of other constraints that sometimes bite in practice — e.g., the FQDN field in a hostname is often capped at 255 by OS buffers, and label content (not just length) is further restricted by the registry rules and the "preferred syntax" RFC 1123 relaxed.
=== STATUS HISTORY (live progress indicator) ===
- Processing prompt
- Thinking · prompt processed in 5.1 s
- Thought: The user is asking about the maximum DNS label length and the maximum domain name length, with RFC citations. Let me look up the relevant RFCs. The classic…
- Calling lookup_rfc
- Calling lookup_rfc
- Thinking
- Thought: The search jumped to the table of contents, not the actual 2.3.4 section. I need to read the actual section 2.3.4 "Size limits". Let me fetch the page at the…
- Writing response
- Calling lookup_rfc
- Calling lookup_rfc
- Thinking
- Thought: I now have the authoritative text from RFC 1035, Section 2.3.4 and Section 3.1. Let me summarize: **RFC 1035, Section 2.3.4 (Size limits):** ``` labels 63…
- Writing response
- Done · 4 tool calls