Re: [idn] New draft: draft-ietf-idn-idna

[James Seng <James@Seng.cc>]

Keith Moore wrote:
> overall, I think this is not only the right approach, but the only
> viable approach.  so consider these comments in light of that.

While I like this approach very much, I am not sure this is THE solution. Lets
keep open mind and watch out for more. I think there are still a viable
solution using Directory/DNS hybrid solution...

> I can see two approaches:
> 
> 1. make DNS servers able to understand IDNs in zone files
>    (meaning that they can understand local charsets, and are able
>    to perform nameprep, RACE, and variant spelling processing on
>    such zone files.  this probably also implies the need to have
>    a charset label in the zone file)
> 
> 2. keep zone files in ASCII and say that any nameprepping, RACE,
>    etc. conversions that are applied to the original need to be
>    handled in a separate preprocessor.  but will IDN zone source
>    files then be in a nonstandard format?
>
> whichever approach is taken - to extend the zone file format or not -
> needs to be documented.

I think the maintance of the zonefile is out of place here. There could be a
dozen of ways to do it. For example, I could think of an additional method, ie
edit zone file in native, then use a pre-processor tool to convert the zone
file to RACE with nameprep which will the DNS then can use. Or there could be
some special editor customized for this where not only you can use it to
manage your zone, you can use it to enter multilingual text etc.

Hence, I think the better approach is to define that the data in the DNS
server is in RACE, namepreped. How DNS server get that would depend on
implementation.

> there's  another possible security consideration - if RACEs can be used
> to encode pure-ascii labels then it becomes possible to have an
> alternate set of DNS records for a particular domain - one of which
> is keyed by the RACEd name and another of which is keyed by
> the ASCII name.

That is not possible according to the algorithm for RACE.

However, an interesting variant of the problem which *might* occur with this
maybe the interaction between nameprep and RACE.

For example, supposing we folding (*) dotless i to Latin i.

Now, given a domain name "*dn.tld" (or idn with a dotless i), should it retain
as "idn.tld" or "race.tld"? 

I see this as an issue for nameprep, not in idna tho. 

> and if a RACEd ASCII name is returned in a response to a DNS query
> (say in an NS or CNAME or MX record), will the application decode
> the RACE and then use the decoded form in a subsequent query, or will it
> use the RACEd name in that query?

There shouldnt be any need for encoding/decoding on the DNS resolver or
server. All DNS function based on RACE should proceed as it is, ie, just ASCII
domain names. 

> applications should probably be required to check for bogus use of
> RACE - any response that could not have been the output of the
> RACE encoder should be considered illegal and should cause an error.

I would say the application should treat bogus RACE as what it is, just ASCII
string. Beside, how would you determine if the RACE is bogus or not without
some form of checksum, or some other ways to verify?

I give my comments on IDNA separately later.

-James Seng