Subject: RFC 2181: What is the maximum length of a domain name?

From: Stuart Cheshire <[email-masked]>
Date: Wed, 30 Apr 2003 11:58:34 -0700

It is well-known that the maximum length of a domain name is 255 octets.

It sounds simple, but what is included in that count?

* Is it the conventional API representation of the name, with text and 
separator dots? Is the final trailing dot included?

* Or is it the on-the-wire representation of the name, with length bytes 
and data bytes? Is the final null root label included?

To illustrate, is the length of "apple.com" considered to be 9, 10 or 11?

(A) Text representation, as commonly written with no trailing dot:
    "apple.com"
    Length = 9

(B) Text representation, with trailing dot:
    "apple.com."
    Length = 10

(C) On-the-wire representation, excluding terminator:
    -----------------------------------------------
    | 0x05 | a | p | p | l | e | 0x03 | c | o | m |
    -----------------------------------------------
    Length = 10

(D) On-the-wire representation, as it actually appears in a packet,
    including final null root label:
    ------------------------------------------------------
    | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
    ------------------------------------------------------
    Length = 11

RFC 1034 seems relatively clear:

>To simplify implementations, the total number of octets that represent a
>domain name (i.e., the sum of all label octets and label lengths) is
>limited to 255.

While this certainly could be more specific, with a little thought it 
seems clear that the LEN("apple.com")=11 interpretation is the correct 
one:

1. The RFC 1034 text above says that *all* label octets and label lengths 
are included in the count. The final 0x00 is the label length byte for 
the zero-length root label at the end, so it is included in the count.

2. The RFC 1034 text above says "the total number of octets that 
represent a domain name". The final 0x00 is an essential part of how you 
represent a domain name in a packet -- if you try to omit it, then it 
won't work. Therefore it is included in the count.

If the intent of RFC 1034 were really to say, "The total number of octets 
that represent a domain name, not counting the final zero," then I think 
it would have said that explicitly. I don't think it is reasonable to 
assume, "Not counting the final zero," unless the text actually says that.

So far, so good. The text could have been clearer, but I think we have 
discerned the correct meaning.

Unfortunately, RFC 2181 "Clarifications to the DNS Specification" 
contradicts this:

>   A full domain
>   name is limited to 255 octets (including the separators).  The zero
>   length full name is defined as representing the root of the DNS tree,
>   and is typically written and displayed as ".".

What is "The zero length full name"? The shortest possible name is just 
one byte long: a single zero byte. That's one byte, not zero bytes. You 
can't put a zero-byte name into a DNS packet.

RFC 1034 is talking about the on-the-wire representation, with length 
bytes and data bytes.

RFC 2181 is talking about the conventional API representation of the 
name, with text and separator dots. RFC 2181 also describes the root 
name, ".", as the "zero length full name", implying that the final dot in 
any name is not counted. This would appear to support the 
LEN("apple.com")=9 interpretation.

There's a discrepancy of *two* between RFC 1034 and RFC 2181.

My current code uses the RFC 1034 interpretation (the total number of 
octets that it takes to represent a domain name in a packet, including 
all label length octets, all label data octets, and the label length 
octet for the terminating root label, so that LEN("apple.com")=11). 
Having given this some thought, I believe this is the correct 
interpretation of RFC 1034, but I'm willing to listen to arguments.

Comments?

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Peter Koch <[email-masked]>
Date: Wed, 30 Apr 2003 21:18:50 +0200

> separator dots? Is the final trailing dot included?

neither - nor. It's the wire format length which is restricted to 255
octets. That's 253 octets with conventional ASCII representation.
The "final trailing dot" is not included, because it's not part of the name,
except for the root.

> and data bytes? Is the final null root label included?

Yes and yes.
That's 255 octets in wire format and 253 in conventional (i.e. no \-style
escapes) ASCII representation. In text format n labels have n-1 intermediate
dots (the "final trailing dot" is not included, because it's
not part of the name), while you need n length octets plus one for the
terminating NUL octet in wire format. That's n - 1 vs. n + 1. For the
ease of the calculation I've assumed that the name consists of "printable"
characters only.

> (C) On-the-wire representation, excluding terminator:

Where would it occur in this form?

> can't put a zero-byte name into a DNS packet.

Unfortunately the use of "separators" suggests that the sentence addresses
a textual representation, for which a maximum length of 255 is wrong.

> Comments?

I remember an old posting by Paul or Mark comparing the different encoding
levels (compressed/uncompressed wire format, text format, expanded text).
Maybe an Informational document on this would help. Fun will increase with IDN.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Apr 2003 17:22:01 -0400

On the wire, the name is 1 to 255 octets, with the smallest being 
'0x00' in the first byte.

As far as printed ("conventional"), if you discount the escaped 
characters, you will have up to 254.  I disagree with Peter about the 
trailing dot - that is included in a formal name.  An API ought to 
allow for it because in some instances (e.g. DHCP options) it is 
allowed to include both partially-qualified and fully-qualified 
domain names.

If you allow for escaped characters, then you will multiple 254 by 4 
and then subtract the minimum number of labels needed to fill up 255 
octects worth of name.  (A label can be only 64 octets long - 
including the length byte.)

So - len label len label len label len label len
       1    63   1    63   1    63   1    61   1   (individ counts)
       1    64  65   128 129   192  193  254 255   (cumulative to reach 255)
      --- ----- --- ----- --- ----- --- ----- ---
value 63  ???  63   ???  63   ???   61  ???   0

It looks to me 4*(63+63+63+61)+5 = 1005 octets for the characters is 
possible (neglecting local encoding and the C-style terminating '\0').

>>  can't put a zero-byte name into a DNS packet.

Something to clean up when we shoot 2181 into Draft Standard.

>Maybe an Informational document on this would help. Fun will 

This is part of why I bristle at defining a standard "presentation" 
format.  On the wire, 255 is 255 - no matter how you cook it up. 
Compression of messages doesn't change the syntactic representation, 
just how the transport is carried out.  Once you go start worrying 
about the presentation (presented) format you get into a rat's nest.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

It's true, my last college class really was "Introduction to Ada."