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/v4/grade.md
+62
View File
@@ -0,0 +1,62 @@
# m09 — RFC precision · round v4
> Grading worksheet for round **v4**. 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 and §3.1 prose
- [x] (1) 255 → 1/1 — likewise, identified as the wire-format total
- [x] (2) RFC 1035, section 2.3.4 → 2/2 — "**RFC 1035**… **§2.3.4 'Size limits'**", with §3.1 quoted for the "label octets and label length octets" qualifier; both sections retrieved in one window and cited by the names the tool's section note gave them
- [x] (1) Explains 253 vs 255 correctly (representation difference, not a contradiction) → 1/1 — "Both numbers are correct — they're just counting different things", with the derivation written out: wire = Σ(label lengths) + #labels + 1; text without trailing dot = Σ(label lengths) + (#labels − 1); difference 2 ⇒ text ≤ 253. Equivalent to the rubric's "255 − the leading length byte − the trailing root byte" and shown to hold for any label count
### Calibration & honesty (2)
- [x] (1) Quotes or closely paraphrases the RFC text it retrieved → 1/1 — the §2.3.4 table reproduced as a code block and two §3.1 sentences blockquoted, all verbatim against the tool output. Thinking block [1] had recalled section numbers and wording that do not exist ("Section 2.3.3 (Domain names) states: 'Each label must be 63 octets or less.' And Section 4.1.4 (Character-string encoding) states…"), used them as search terms, was told twice that the phrases "do not appear in RFC 1035… do not state it as this RFC's content", and replaced them with the real text
- [x] (1) Does not add limits it did not read (e.g. a "127 labels" claim) → 1/1 — no added limits, no added attribution. The closing caveat (the RFC "technically permits arbitrary 8-bit values in labels") is §3.1's own sentence, in the window
### Tool use (2)
- [x] (2) `lookup_rfc`. 0 if from memory, even if right. → 2/2 — five `lookup_rfc` calls: a topic query (NO RESULTS), two recalled-phrase searches (both missed; the opening shown), then `search: "63 octets"` ∥ `search: "255 octets"`, both landing on §2.3.4 with §3.1 in the same window. The answer is built on the last two
### Communication (1)
- [x] (1) Numbers, citation, one-paragraph reconciliation → 1/1 — verdict first, the two citations quoted, the derivation as a four-line block, a three-row summary table, a two-bullet bottom line. About 380 words — the same length as v3, answer-first, no padding
### Automatic deductions
- −2 wrong section → not applied
- −2 says 253 is "the RFC limit" or that 255 is wrong → not applied — "**255**… *this is what the RFC literally says*"; "**253**… Convention, not a separate RFC number… consistent with — not contradictory to — the 255-octet wire limit"
- −1 intent-without-call → not applied — every "let me look up / search for" 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-12T04:37:21Z (dumped 04:39:17Z)
- Model tag / Open WebUI version: qwen3.8:latest / Open WebUI 0.11.3
- Tool calls, in order (copy from the `result.txt` header): 5 — `lookup_rfc` {query: "DNS domain name maximum length 63 octets label 255 character string encoding"} → NO RESULTS; `lookup_rfc` {1035, search: "Each label must be 63 octets or less"} ∥ {1035, search: "255 octets or less in length"} → both missed, opening shown; `lookup_rfc` {1035, search: "63 octets"} ∥ {1035, search: "255 octets"} → §2.3.4
- Wasted, failed, or repeated calls: three of five produced nothing usable, all model-caused and all recovered: the topic query carries no title words (the index search matches titles, and "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" shares none of them); the two phrase searches were recalled pseudo-quotations, and the miss text told the model so in terms. The last pair is v3's single well-aimed call, twice. Net: 5 calls for what v3 did in 1 (+1 redundant search)
- Prefill time / total time / tokens (from the `usage:` line in `result.txt`): prefill=4.2s / total=77.1s (decode=72.9s, 36.9 tok/s) / prompt_eval_count=15523 (final round), completion_tokens=2688; status line: 3,362 generated (v3: 4,742)
- 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 — five `Calling lookup_rfc` lines, `Done · 5 tool calls · prefill 5.0 s for 12,785 tokens · 3,362 generated`
- Anything odd (loops, truncation notices, tool errors, effect of the inlet nudge): the 54-second final thinking block derives the 253 three times — "chars = wire − 2 ≤ 253… Wait, but I need to double check… Hmm, let me redo" — and lands right each time, the same convergent circling v3's grade recorded for this prompt. The two phrase misses are a good instance of the 54.3 miss text doing its job: "It may be defined in a different RFC, or named differently here - do not state it as this RFC's content", and the model searched for the numbers instead of the sentences. Section note `'2.3.4. Size limits'` correct on both hits. Nudge does not fire (no unit)
### Change 55 checks (this round's changes — fill in even when they did not fire)
- Did a tool result carry a `Sources:` trailer? (y/n): **y** — on all four body reads: `Sources: RFC 1035 - https://www.rfc-editor.org/rfc/rfc1035.txt`
- Did the answer end with a URL — written by the model, or appended by the `answer_sources` filter? (model / filter / none): **filter** — the RFC 1035 URL; the body cites §2.3.4 and §3.1 by number, which is what the prompt asked for, and links nothing. First URL on this prompt in four rounds
- Any of the 55.2 tool fixes exercised? Which, and did it fire correctly?: the **`lookup_rfc` description change** ("also answers 'which RFC says X'") is consistent with the model's first call being a topic query to `lookup_rfc` — but the query got NO RESULTS because it carried no title words, so the description's promise was not kept by the index search on this input. The **contents-entry skip** was not needed (value-shaped search terms land on the body, as in v3); the section note is Change 54.3's and was correct
## 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, quoted verbatim; the 253/255 reconciliation derived correctly with the arithmetic shown; recalled section numbers and pseudo-quotations tested against the RFC and discarded when the tool said they were not there; a URL
- **What it got wrong:** nothing scored. Three of five calls were spent testing recall that the tool refuted, and the final derivation was done three times
- **Change from the previous round:** **10 → 10 (0)** on score; the retrieval path is noisier. v3's one lookup with a value-shaped search term became five calls, three of them the model checking its own wrong recollections (§2.3.3, §4.1.4, two invented sentences) against the document — which is the right thing to do with a wrong recollection, and the tool's miss text is what made it cheap. The answer is v3's answer with the same derivation and a table; the URL is new (filter). The `lookup_rfc` topic query returning NO RESULTS on a description-shaped question is the one harness-side note
- **Worth recording in TUNING.md?** (only if it exposes a harness or prompt weakness): **one small item.** 55.2 changed `lookup_rfc`'s description to say it answers "which RFC says X", and the first thing the model did on a "which RFC says X" question was ask it that — and get NO RESULTS, because the index search is a title search. Either the description should say "by title or topic keywords" or the NO RESULTS text for a `query` should suggest the two or three RFCs most people mean by the topic words present (DNS → 1034/1035; HTTP → 9110…), which is a small table. Positive: 54.3's miss text steered the model off two pseudo-quotations without a wasted answer
## Grader notes
- Ground truth verification: the rubric's own verification stands; all three quoted passages (the §2.3.4 table, the two §3.1 sentences) are in the tool output verbatim. The derivation checked independently: with k labels, wire = Σ + k + 1 ≤ 255 and text without trailing dot = Σ + (k − 1) = wire − 2 ≤ 253, for any k. The thinking's a.b.c worked example (wire 7, text 5) is right
- Rubric issues: none
docs/testing/prompt-corpus/medium/m09-dns-name-limits/v4/result.txt
+752
View File
@@ -0,0 +1,752 @@
########################################################################
# owuitools prompt test result
# prompt dir : medium/m09-dns-name-limits (round v4)
# chat id : ca28b938-e0d6-4565-92d0-13fe7aec422f
# chat title : DNS Label Length and Domain Name
# user : the operator
# model : qwen3.8:latest
# turns : 2 messages on selected branch
# tool calls : 5 lookup_rfc x5
# dumped at : 2026-09-12T04:39:17Z
########################################################################
=== USER (2026-09-12T04:37:21Z) ===
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-12T04:37:21Z, model qwen3.8:latest) ===
usage: prompt_eval_count=15523 eval_count=2688 prompt_tokens=15523 completion_tokens=2688 total=77.1s prefill=4.2s decode=72.9s 36.9 tok/s
=== [1] THINKING ===
The user is asking about the maximum length of a DNS label (63 octets) and the maximum length of a full domain name (255 octets), and wants me to cite the specific RFC number and section. The confusion point is between 253 and 255.
Let me recall: in the DNS wire format, the domain name field is 255 octets or fewer, but this includes the root label (1 byte for the root label terminator). So the maximum for a fully qualified domain name excluding the trailing root dot is 253 characters. But the RFC specifies the limit as 255 octets total for the <length> field.
Let me look up the actual RFC to be precise and cite correctly. The relevant RFC is RFC 1035 (the original DNS spec) and RFC 1034. Let me verify by looking at the RFC.
RFC 1035, Section 2.3.3 (Domain names) states: "Each label must be 63 octets or less." And Section 4.1.4 (Character-string encoding) states the domain name is "255 octets or less in length."
Let me actually pull the RFC to confirm the exact section numbers and wording rather than relying on memory.
=== [2] TOOL CALL: lookup_rfc (call_7gnngvni) ===
{
"query": "DNS domain name maximum length 63 octets label 255 character string encoding"
}
=== [3] TOOL RESULT: lookup_rfc (call_7gnngvni) ===
NO RESULTS. No RFC title matches 'DNS domain name maximum length 63 octets label 255 character string encoding'. 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.
=== [4] THINKING ===
The query-based search didn't match. Let me read RFC 1035 directly, which is the DNS spec. The relevant sections are 2.3.3 (Domain names) and 4.1.4 (Character-string encoding).
=== [5] TOOL CALL: lookup_rfc (call_pnxinlsv) ===
{
"number": 1035,
"search": "Each label must be 63 octets or less"
}
=== [6] TOOL CALL: lookup_rfc (call_064v0aom) ===
{
"number": 1035,
"search": "255 octets or less in length"
}
=== [7] TOOL RESULT: lookup_rfc (call_pnxinlsv) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
'Each label must be 63 octets or less' does not appear in RFC 1035. It may be defined in a different RFC, or named differently here - do not state it as this RFC's content.
[Showing the opening of the document instead, so the call is not wasted. The document itself is fine; only the search term missed.]
Network Working Group P. Mockapetris
Request for Comments: 1035 ISI
November 1987
Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1. STATUS OF THIS MEMO
This RFC describes the details of the domain system and protocol, and
assumes that the reader is familiar with the concepts discussed in a
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
The domain system is a mixture of functions and data types which are an
official protocol and functions and data types which are still
experimental. Since the domain system is intentionally extensible, new
data types and experimental behavior should always be expected in parts
of the system beyond the official protocol. The official protocol parts
include standard queries, responses and the Internet class RR data
formats (e.g., host addresses). Since the previous RFC set, several
definitions have changed, so some previous definitions are obsolete.
Experimental or obsolete features are clearly marked in these RFCs, and
such information should be used with caution.
The reader is especially cautioned not to depend on the values which
appear in examples to be current or complete, since their purpose is
primarily pedagogical. Distribution of this memo is unlimited.
Table of Contents
1. STATUS OF THIS MEMO 1
2. INTRODUCTION 3
2.1. Overview 3
2.2. Common configurations 4
2.3. Conventions 7
2.3.1. 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
…
[This is the opening only - 109,114 characters follow. To read on, call lookup_rfc with number=1035 and offset= to read more.]
---
Sources: RFC 1035 - https://www.rfc-editor.org/rfc/rfc1035.txt
=== [8] TOOL RESULT: lookup_rfc (call_064v0aom) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
'255 octets or less in length' does not appear in RFC 1035. It may be defined in a different RFC, or named differently here - do not state it as this RFC's content.
[Showing the opening of the document instead, so the call is not wasted. The document itself is fine; only the search term missed.]
Network Working Group P. Mockapetris
Request for Comments: 1035 ISI
November 1987
Obsoletes: RFCs 882, 883, 973
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1. STATUS OF THIS MEMO
This RFC describes the details of the domain system and protocol, and
assumes that the reader is familiar with the concepts discussed in a
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
The domain system is a mixture of functions and data types which are an
official protocol and functions and data types which are still
experimental. Since the domain system is intentionally extensible, new
data types and experimental behavior should always be expected in parts
of the system beyond the official protocol. The official protocol parts
include standard queries, responses and the Internet class RR data
formats (e.g., host addresses). Since the previous RFC set, several
definitions have changed, so some previous definitions are obsolete.
Experimental or obsolete features are clearly marked in these RFCs, and
such information should be used with caution.
The reader is especially cautioned not to depend on the values which
appear in examples to be current or complete, since their purpose is
primarily pedagogical. Distribution of this memo is unlimited.
Table of Contents
1. STATUS OF THIS MEMO 1
2. INTRODUCTION 3
2.1. Overview 3
2.2. Common configurations 4
2.3. Conventions 7
2.3.1. 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
…
[This is the opening only - 109,114 characters follow. To read on, call lookup_rfc with number=1035 and offset= to read more.]
---
Sources: RFC 1035 - https://www.rfc-editor.org/rfc/rfc1035.txt
=== [9] THINKING ===
The exact phrases I searched for don't appear verbatim. Let me find the actual wording. The "Size limits" section is 2.3.4, and the character-string encoding is in section 4.1.4 (well, actually 4.1.4 is message compression; the character-string encoding is a different subsection). Let me search for the actual terms.
Let me search for "63 octets" and "255 octets" and "character-string".
=== [10] TOOL CALL: lookup_rfc (call_vc3h020e) ===
{
"number": 1035,
"search": "63 octets"
}
=== [11] TOOL CALL: lookup_rfc (call_sxefiki1) ===
{
"number": 1035,
"search": "255 octets"
}
=== [12] TOOL RESULT: lookup_rfc (call_vc3h020e) ===
# RFC 1035
Source: https://www.rfc-editor.org/rfc/rfc1035.txt
[Jumped to '63 octets' at character 23,832 of 114,114; this is inside the section '2.3.4. Size limits']
…
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 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
=== [13] TOOL RESULT: lookup_rfc (call_sxefiki1) ===
# 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
=== [14] THINKING (54s) ===
I now have the authoritative text from RFC 1035. Let me answer clearly.
Key facts:
- Label max: 63 octets (RFC 1035 §2.3.4 "Size limits" and §3.1 "Name space definitions")
- Name max: 255 octets total (RFC 1035 §2.3.4 and §3.1)
The 253 vs 255 distinction: The 255 octet limit is the *total length of a domain name* including label octets AND label length octets (the wire format). This includes the terminating zero-length root label byte. So in a fully qualified name, the 255 octets include the trailing root dot (1 byte for the null label terminator).
So where does 253 come from? The 255-octet wire-format limit includes:
- All label content octets
- All label length octets (one per label)
- The final 1-octet null terminator (root label)
If you count only the printable characters (label octets + dots), the maximum is less than 255. But the commonly cited "253 characters" figure comes from a slightly different framing.
Actually, let me think carefully about where 253 comes from. The typical explanation:
The DNS name in wire format is at most 255 octets. This 255 includes the 1-byte root label (the trailing null/zero length byte that terminates the name). So the actual "name" excluding the root is 254 octets of data plus... hmm.
Let me be precise. A domain name in wire format = sequence of (length byte + label bytes) ... ending with a single zero byte (the root).
Total ≤ 255 octets.
The zero byte for the root = 1 octet. So the rest (all labels + their length bytes) ≤ 254 octets.
Now, in a text representation like "a.b.c", the dots are separators not stored in wire format. The wire format stores each label's length byte + its content. So if we're counting the number of *characters* in the dotted form (letters/digits/hyphens + dots), that equals (sum of label lengths) + (number of dots). Number of dots = number of labels (for a fully-qualified name without trailing dot). Sum of label lengths + number of labels = sum over labels of (label length + 1) = total wire octets minus the root terminator byte. So characters in dotted form (no trailing dot) ≤ 254.
Hmm, so where does 253 come from? Let me reconsider.
Actually the common convention: many references say the maximum DNS name is 253 characters. This comes from the reasoning that the 255 octets includes the trailing null byte AND... no.
Let me reconsider. There are a few numbers floating around:
- 255: the wire-format limit including the root label byte.
- 253: often cited as the maximum "character" length.
The 253 figure: If you have a name with the maximum of 255 octets in wire format, and you want to express it as a dotted string WITHOUT the trailing dot, you get 254 characters (as I computed: wire octets minus the 1 root byte = 254, which equals content + dots). Wait, that gives 254, not 253.
Let me recompute carefully. Wire format for name "a.b.c":
- 1 'a' → length byte (1) + 'a' (1) = 2 octets
- 1 'b' → 2 octets
- 1 'c' → 2 octets
- root terminator → 1 octet (zero)
Total wire = 7 octets.
Dotted form "a.b.c" = 5 characters (3 letters + 2 dots).
So wire octets = 7, chars = 5. Difference = 2 = number of labels (each label contributes one extra length byte beyond its content, and the root contributes one byte). Actually: wire = sum(label_len + 1) + 1(root). For single-char labels: 3*(1+1)+1 = 7. Chars = sum(label_len) + (n_labels - 1) [dots between] = 3 + 2 = 5.
General: wire = Σ(len_i) + n_labels + 1. chars (no trailing dot) = Σ(len_i) + (n_labels - 1). So wire = chars + 1 + 1 = chars + 2? Let's check: wire - chars = [Σlen + n + 1] - [Σlen + n - 1] = 2. Yes! So for a name without trailing dot, wire octets = chars + 2. Therefore chars = wire - 2 ≤ 255 - 2 = 253.
There it is. So the 253 figure = maximum number of characters in the dotted representation WITHOUT a trailing dot, when the full wire format (including the root terminator) is at the 255-octet limit.
Wait, but I need to double check the "chars" count includes dots. Σ(len_i) is the total label content (letters/digits/hyphens), and (n_labels - 1) is the number of internal dots. So chars = total letters + internal dots. For "a.b.c": 3 + 2 = 5. ✓.
So:
- Wire format limit: 255 octets (RFC 1035 §2.3.4, §3.1) — this is the authoritative RFC statement.
- Maximum characters in the textual (dotted) form without trailing dot: 253 (= 255 − 1 root byte − 1... no wait).
Hmm, let me redo. wire = Σlen + n + 1 where n = number of labels. chars_no_trailing_dot = Σlen + (n−1).
wire − chars = (Σlen + n + 1) − (Σlen + n − 1) = 2.
So chars = wire − 2 ≤ 253. Yes.
The two subtracted bytes are: (1) the root terminator byte, and (2) one length byte that isn't represented by a dot (the first label has a length byte but no preceding dot). Actually more precisely: each label has a length byte; in text, all but... hmm, the mapping is: n labels → n length bytes in wire, but n−1 dots in text (no trailing dot). So there's exactly one "extra" length byte (for the last/first label) plus the root byte = 2 extra octets vs. text chars. That's the 2.
So both numbers are "right" but refer to different things:
- 255 = RFC's stated limit on the total wire-format length (label octets + length octets + root). This is what the RFC actually says.
- 253 = the practical maximum count of characters in the human-readable dotted form (without the trailing dot), derived from the 255-octet wire limit.
So the answer: The RFC says 255 (total octets including length bytes and the root label). 253 is the maximum number of characters in the textual representation. Both are consistent; they're counting different things.
Also worth noting: this is about the *preferred* syntax / ASCII character counts. The RFC technically allows arbitrary 8-bit values in labels, so "characters" isn't strictly defined for non-ASCII, but for the common case the 253-char figure holds.
Let me also note that RFC 1035 is the original; it hasn't been obsoleted for these limits. Some might cite RFC 1034 (concepts) too, but the size limits table is in RFC 1035 §2.3.4. Let me confirm RFC 1034 doesn't have a separate statement — actually the "size limits" table is specifically in RFC 1035. I'll cite RFC 1035 §2.3.4 and §3.1.
I'm confident in the answer now. No need for more tool calls. Let me write a clear, well-structured response.
Let me make sure about section numbers:
- §2.3.4 "Size limits": the table with labels 63, names 255. ✓
- §3.1 "Name space definitions": the prose explaining label ≤ 63 octets (from the 6-bit length field) and total name ≤ 255 octets. ✓
Good. Let me write the answer.
=== [15] ASSISTANT TEXT ===
Both numbers are correct — they're just counting different things. Here's what the RFC actually says.
## The authoritative statement
**RFC 1035** (*Domain Names — Implementation and Specification*) gives both limits in two places:
**§2.3.4 "Size limits"** (the summary table):
```
labels 63 octets or less
names 255 octets or less
```
**§3.1 "Name space definitions"** (the explanation):
> "…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 per the RFC:
- **Single label:** max **63 octets**
- **Full name:** max **255 octets** total
## Where 253 comes from
The key phrase is *"label octets **and label length octets**."* The 255-octet limit is the **wire-format** size, which includes:
- every label's content bytes, **plus**
- one length byte per label, **plus**
- the final 1-octet null byte that terminates the name (the root label).
When you write the name as a human-readable dotted string (`a.b.c`), the dots and the first label don't map onto those extra bytes, so the count of *characters* (letters/digits/hyphens + separating dots, no trailing dot) is two fewer than the wire octets:
```
wire octets = Σ(label lengths) + (#labels) + 1 (root terminator)
text chars = Σ(label lengths) + (#labels − 1) [dots between labels]
─────────────────────────────────────────────────────────────────────
wire octets = text chars + 2 → text chars ≤ 255 − 2 = 253
```
So:
| Figure | What it measures | Source |
|---|---|---|
| **63** | Max octets in one label | RFC 1035 §2.3.4, §3.1 |
| **255** | Max total wire-format length (label bytes + length bytes + root byte) | RFC 1035 §2.3.4, §3.1 — *this is what the RFC literally says* |
| **253** | Max characters in the dotted textual form (no trailing dot), derived from the 255 limit | Convention, not a separate RFC number |
## Bottom line
- If you're quoting **the RFC**, cite **RFC 1035 §2.3.4 / §3.1**: label ≤ 63 octets, name ≤ **255 octets**.
- The **253** figure is the correct maximum for the *textual* name (what you'd type or validate in code), and it's consistent with — not contradictory to — the 255-octet wire limit.
One caveat: the 253/255 counts assume the *preferred* ASCII syntax. The RFC technically permits arbitrary 8-bit values in labels, so "character" counts only have a clean meaning for the common alphanumeric case.
---
Sources: https://www.rfc-editor.org/rfc/rfc1035.txt
=== STATUS HISTORY (live progress indicator) ===
- Processing prompt
- Thinking · first token after 5.1 s
- Thought: The user is asking about the maximum length of a DNS label (63 octets) and the maximum … section numbers and wording rather than relying on memory.
- Calling lookup_rfc
- Thinking
- Thought: The query-based search didn't match. Let me read RFC 1035 directly, which is the DNS … are 2.3.3 (Domain names) and 4.1.4 (Character-string encoding).
- Calling lookup_rfc
- Calling lookup_rfc
- Thinking
- Thought: The exact phrases I searched for don't appear verbatim. Let me find the actual wording. … search for "63 octets" and "255 octets" and "character-string".
- Calling lookup_rfc
- Calling lookup_rfc
- Thinking
- Thought: I now have the authoritative text from RFC 1035. Let me answer clearly. Key facts: - … - 1) is the number of internal dots. So chars = total letters
- Writing response
- Done · 5 tool calls · prefill 5.0 s for 12,785 tokens · 3,362 generated