########################################################################
# 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
