Re: [idn] length restrictions on IDN label

[Mark.Andrews@isc.org]

> Mark.Andrews@isc.org wrote:
> 
> >> 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).
> >
> If you have a linux (Redhat) box, "chdir /usr/include; grep MAXHOST */*".
> Then you will get the enclosed header lists.
> Many applications headers use 64/65/257 except for resolver/network
> libraries headers which
> use 1024/1025 for FQDN. If you have openssh 3.4p1 sources, you can find
> that it uses MAXHOSTNAMELEN (64) in
> some place in addition to 1025 in other places. of course, 64 is for a
> hostname label length.
> See rpc/* headers.

	Repeat after me: "HOSTNAME != DOMAIN NAME".

	Hostnames are a subset of domain names (ignoring hostnames
	that are larger that 253 and hence not supported by the
	DNS).  If you are only dealing with hostnames then you
	should be rejecting domain names that are not legal hostnames.
	Anything reading unsanitized domainnames has to expect a
	strings bigger than 255 when converted to RFC 1034 presentation
	format.

	Some implementations of gethostbyaddr() do this sanitization
	for you.  This was also one of the reasons IDNs are converted
	to and from ACSII.  ToUnicode should be perform outside of
	gethostbyaddr().  Moving it inside of gethostbyaddr() is a API
	change.

	Mark

> asm/param.h:#define MAXHOSTNAMELEN 64 /* max length of hostname */
> imap/mail.h:#define NETMAXHOST 65
> imap/mail.h: char host[NETMAXHOST]; /* host name (may be canonicalized) */
> imap/mail.h: char orighost[NETMAXHOST]; /* host name before
> canonicalization */
> lwres/netdb.h:#undef NI_MAXHOST
> lwres/netdb.h:#define NI_MAXHOST 1025
> mozilla/plresolv.h:#define PL_RESOLVE_MAXHOSTENTBUF 1024
> protocols/timed.h: char tsp_name[MAXHOSTNAMELEN];
> rpcsvc/rusers.h:#define RUSERS_MAXHOSTLEN 257
> rpcsvc/rusers.x:const RUSERS_MAXHOSTLEN = 257;
> rpcsvc/rusers.x: string ut_host<RUSERS_MAXHOSTLEN>; /* host user logged
> on from */
> rpc/types.h:#ifndef MAXHOSTNAMELEN
> rpc/types.h:#define MAXHOSTNAMELEN 64
> w3c-libwww/wwwsys.h:#ifndef MAXHOSTNAMELEN
> w3c-libwww/wwwsys.h:#define MAXHOSTNAMELEN 64 /* Any better ideas? */
> X11/Xos_r.h: char h_name[MAXHOSTNAMELEN];
> 
> 
> >
> >	As I said what you are talking about is NOT new.  These
> >	issues have existed for years.
> >
> yes, for presentation formats, it is not new. But for protocol elements,
> it is new. isn't it ?
> 
> Soobok Lee
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org