Subject: [dnsext] FQDN maximum length

From: Donald Eastlake <[email-masked]>
Date: Sun, 13 Dec 2009 21:48:08 -0500

OK, here is what I think is a stupid question to which I think I know the
answer... but I wish to consult the wisdom of namedroppers.

I am doing a review of draft-cheshire-dnsext-multicastdns-08.txt. For some
reason, the authors believe that the words of RFC 1034 as follows

     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

are no clear. I thought they were clear. "all label octets and label
lengths" seems clear and should include zero byte which is the length of the
root label. That is to say, I thought that "all" meant "all". So, if you had
a maximum length wire encoded FQDN, the last or 255th byte would be that
zero length... The authors of the cheshire draft then, however, refer to RFC
2181 "Clarifications to the DNS Specification" where it says

   The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".

from which they conclude that the "length" of an FQDN does not include
the zero byte which is the length of the root label. (Looking further
at RFC 2181, the preceding sentence says "A full domain name is
limited to 255 octets (including the separators)." which seems beside
the point. The length limit in RFC 1034 is defined in terms of the
wire encoding with byte counts, not the ASCII encoding with period
separators.)

So, the authors of this draft have decided that they want their
maximum length to include the zero byte which is the length of the
root label and they specify the maximum length to be 256 bytes. They
presumably believe this is what the regular DNS length limit "really
means"...

So, what's the real story here?

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 14 Dec 2009 14:27:49 +1100

In message <[email-masked]>, Donal
> So, what's the real story here?

The wire limit is 255 octets.  The presentation limit is 1004 bytes.
1005 bytes for null terminated C strings.  The biggest hostname
(LDH) which can be wire encoded is 253 bytes.  Note hostnames do
not have a trailing period.

1004 = (63 + 63 + 63 + 61) * 4 (\DDD encoded labels characters) +
       4 (periods at end of labels)

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 13 Dec 2009 22:38:14 -0500

That's exactly what I thought. So an example of the wire encoding of a
maximum length FQDN could be four labels of 63, 63, 63, and 61 bytes = 250
bytes plus the one byte lengths for these four labels plus the one byte of
value zero for the terminating root label = 250 + 4 + 1 = 255 bytes.

Thanks,
Donald

---

From: Bob Halley <[email-masked]>
Date: Mon, 14 Dec 2009 07:09:53 -0800

On 14 Dec 2009, at 02:48, Donald Eastlake wrote:

OK, here is what I think is a stupid question to which I think I know the answer... but I wish to consult the wisdom of namedroppers.

I am doing a review of draft-cheshire-dnsext-multicastdns-08.txt. For some reason, the authors believe that the words of RFC 1034 as follows

are no clear. I thought they were clear. "all label octets and label lengths" seems clear and should include zero byte which is the length of the root label. That is to say, I thought that "all" meant "all". So, if you had a maximum length wire encoded FQDN, the last or 255th byte would be that zero length...

I too think that it is clear.  As further proof, I offer

RFC 1034, section 3.1:

 "Each node has a label, which is zero to 63 octets in length.  Brother nodes may not have the same label, although the same label can be used
for nodes which are not brothers.  One label is reserved, and that is the null (i.e., zero length) label used for the root.

"The domain name of a node is the list of the labels on the path from the node to the root of the tree.  By convention, the labels that compose a domain name are printed or read left to right, from the most specific (lowest, farthest from the root) to the least specific (highest, closest to the root)."

While this doesn't specifically say the the root node of the tree is included in the path, it can be reasonably inferred by the fact that the root label is defined, which you wouldn't need to do in the case where the root wasn't included.

In other words, the root domain name is "the list consisting of a single element, namely the null label", and not "the empty list".

RFC 1035 section 3.1 supports this interpretation:

"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."

The authors of the cheshire draft then, however, refer to RFC 2181 "Clarifications to the DNS Specification" where it says

   The zero

This section of RFC 2181 is somewhat confusing, as it's talking about both "octets" and "separators" in the same sentence -- "octets" implies wire encoding, but "separators" implies text encoding.

I think RFC 1034 and 1035 are very clear, and that RFC 2181 should have said something more like

'The domain name of the root of the DNS tree is represented by a label sequence consisting of the the null label.  The textual form of this name is ".".'

/Bob

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 30 Dec 2009 17:02:38 -0800

On 13 Dec 2009, at 18:48, Donald Eastlake wrote:

> OK, here is what I think is a stupid question to which I think I  
> know the answer... but I wish to consult the wisdom of namedroppers.
>
> I am doing a review of draft-cheshire-dnsext-multicastdns-08.txt.  
> For some reason, the authors believe that the words of RFC 1034 as  
> follows
>
> are no clear. I thought they were clear.
As is often the case, things that may superficially appear clear at a  
casual glance are not so clear when you think about them more carefully.

RFC 1035 ("DNS Implementation and Specification") says:

> 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
It would be nice if this said either:

> labels          63 octets or less (including initial length byte)
> names           255 octets or less (including final terminating zero)
or

> labels          63 octets or less (excluding initial length byte)
> names           255 octets or less (excluding final terminating zero)
Other context leads us to conclude that the label length limit does  
NOT include the initial length byte. Consistency would suggest that an  
equivalent interpretation might apply to the definition of name length  
limit.

Faced with this ambiguity, we consulted "Clarifications to the DNS  
Specification", RFC 2181.

Given that the entire point of RFC 2181 was to recognize and remedy  
ambiguities in the original DNS specifications, one might hope that it  
was given thorough scrutiny by the IETF and DNSEXT to ensure that it  
did so, and consequently any information in it replaces and supersedes  
any unclear or ambiguous information in the earlier RFCs. RFC 2181 says:

>    The DNS itself places only one restriction on the particular labels
>    that can be used to identify resource records.  That one  
> restriction
>    relates to the length of the label and the full name.  The length  
> of
>    any one label is limited to between 1 and 63 octets.  A full domain
>    name is limited to 255 octets (including the separators).  The zero
So, what do we make of that? Is this talking about the wire format of  
a domain name, or the conventional textual representation? The  
"including the separators" text implies this is talking about the  
textual representation, but it fails to say whether the trailing dot  
is included, and it also fails to say whether the trailing null byte  
typically at the end of a C string is included. As "clarifications"  
go, I've seen better. What's the length of "ietf.org"? Let's consider  
the four possibilities:

(A) "ietf.org"    length =  8
(B) "ietf.org."   length =  9
(C) "ietf.org\0"  length =  9
(D) "ietf.org.\0" length = 10

Let's consider that for the case of the root name:

(A) ""            length =  0
(B) "."           length =  1
(C) "\0"          length =  1
(D) ".\0"         length =  2

Is the length of "ietf.org" 8, 9 or 10? Is the length of the root name  
0, 1, or 2? If only the document gave us some hint. Oh, wait, it does:

>    The zero length full name is defined as representing the root
>    of the DNS tree, and is typically written and displayed as ".".
So RFC 2181 does tell us the answer. The length of "." is considered  
to be zero. So neither the trailing dot nor the trailing C-string null  
byte are included. That means interpretation (A) is the correct one,  
and the nominal "length" of "ietf.org" is 8.

This is consistent with other similar things in computing. A pascal  
string can be 0-255 bytes long, but it takes 1-256 bytes of storage,  
because of the length byte. Many software objects are a multiple of a  
power of two in size, because computers are more efficient at handling  
memory objects that are bus-aligned (typically 4 bytes), or cache-line  
aligned (e.g. 128-bytes), or VM-page aligned (e.g. 4KB).

Limiting a domain name to 255 bytes of storage instead of 256 is just  
wasting a byte. In a C structure in memory, a 255-byte object is  
usually followed by an unused padding byte so that the next object is  
word-aligned.

In such a world, where a pascal string can be 0-255 bytes long, and  
takes up to 256 bytes of storage, because of the length byte, it is  
consistent that:

(a) a domain label can be up to 63 bytes long (and takes up to 64  
bytes of storage, because of the length byte) and
(b) a domain name can be up to 255 bytes long (and takes up to 256  
bytes of storage, because of the terminating zero).

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Dec 2009 13:26:52 +1100

In message <[email-masked]>, Stuart Cheshire wr
> > names           255 octets or less (excluding final terminating zero)

What actually says is:

labels		63 octets or less plus a length octet.
names           255 octets or less terminating in the root label.

which matches neither of your interpretions.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 31 Dec 2009 04:13:41 +0000

> From: Mark Andrews <[email-masked]>
> Date: Thu, 31 Dec 2009 13:26:52 +1100
> 
> What actually says is:
> 

agreed...

> which matches neither of your interpretions.

...sadly.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 31 Dec 2009 06:57:47 -0800

> which matches neither of your interpretions.

Which page of which RFC are you quoting there?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jan 2010 10:04:04 +1100

In message <[email-masked]>, Stuart Cheshire wr
> Which page of which RFC are you quoting there?

RFC 1034

Internally, programs that manipulate domain names should represent them
as sequences of labels, where each label is a length octet followed by
an octet string.  Because all domain names end at the root, which has a
null string for a label, these internal representations can use a length
byte of zero to terminate a domain name.

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.