Re: length restrictions on IDN label

> [email protected] wrote:
> 
> >	Well if you use raw utf-8 today int the DNS you are limited to
> >	63 octets per label.  255 octets for a domain name.  As long as
> >	you continue to use the same label encoding you are limited to
> >	63 octets.  YMMV at levels other than the DNS.
> >
> Sure.
> If the limit may vary at levels (applications)other than the DNS, the
> utf8 labels may exceed 63 octets
> in appliction protocol formats (not for display) and the implementors
> should reserve enough buffer
> spaces for ToUnicoded(ACE) utf8 labels. This really matters because many
> programmers favor
> utf8 as internal representation format of unicode strings for its ascii
> compatibility.
> 
> Most applications programmer have been reserving 256 bytes for any LDH
> FQDN buffer space .

	Most applications will use NS_MAXDNAME or MAXDNAME to store
	a domain name today as that is enough to cover all the
	potential expansions from wire to RFC 1034 presentation
	format.  Have a look at NS_MAXDNAME in <arpa/nameser.h>.
	Unless you have a really old OS it will be at least (250*4
	+ 5) (minimum number of label that can appear in a full
	length domain name is 4 labels + root, all 4 periods +
	null).

	As I said what you are talking about is NOT new.  These
	issues have existed for years.

> But that convention should be changed to cover the cases of long utf8
> IDN FQDN which may be
> 3 or 4 times longer than 256 octets. So, 1024 or 768 bytes are good. But
> those utf8 FQDN cannot
> be put into single UDP packet of DNS response/query. This will constrain
> future DNS protocol
> update efforts around utf8 supports in wire format. TOday's long iDNs
> may be one of the obstacles
> in the way to the effort.

	That was one of the reasons why raw utf8 was rejected for the wire,
 
> If this warning is neglected by application programmers,
> some remote malicious crackers will send to users' applications long ACE
> IDNs manufactured to
> cause buffer overflow errors when toUnicoded and seaze control of the
> machine.

	FUD.
 
> 
> Soobok Lee
> 
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]