> Mark Andrews said:
> > UTF8 does not require a server upgrade
>
> D. J. Bernstein answered:
> > Right. But Patrik and Paul claim the opposite. This claim is, in fact,
> > the centerpiece of the IDNA ``design philosophy.''
>
> Not so. We all know the servers can handle 8 bit domain names. What
> the servers can't tell, however, is whether some 8 bit string is UTF-8
> or some local encoding, and that presents a security problem. To use
> UTF-8 at the server, the protocol would need to be updated so that a
> client could affirmatively declare, "I'm IDN-aware, and thus my
> request is using UTF-8, not some other local encoding."
>
And this is outside of the servers responsability. It is the
responsability the person entering the data to ensure that it
is in valid and of the clients to ensure that answers are within
the expected range.
Anything else will break clients that expect existing behaviour
like you can have a 0x00 as a octet in a label.
BIND 8 had a tri state check-names fail/warn/ignore.
A future server might want utf8-check fail/warn/ignore. The default
on the master should implementation dependent. The slave
and caching servers should default to warn/ignore.
A future server may also want ace-convert.
However all this should really be done outside of the server with
tools that produce RFC 103[45] compatible zone files.
Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
