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