Re: [idn] Future difficulties because of IDNA

[Dan Oscarsson <Dan.Oscarsson@trab.se>]

This include comments to what Patrik Fältström, Erik Nordmark and
Dave Crocker wrote.


>> From the discussions I have had on the namedroppers list I see
>> that at least two things will be more difficult when we introduce
>> native UCS in DNS because of IDNA:

As Erik said, "if" is better then "when" and from the what I can see
I think it is possible that it will be ACE forever until DNS is replaced
with DNS-NG (at least that should happen some day). While I very much
dislike solutions layered on top of ASCII due to inefficiency and
due to the big problem with application developers that never
understands that you always must translate from the ASCII layer to
native encoding before interacting with users.

As Patrik said, there is no consensus on the namedroppers list.
Actually there is very little response except from Erik.

>> 
>> 1) Additional overhead.
>>     This is because of IDNA, a UCS client MUST first query the server
>>    if the server can handle UCS, and then send the real query.
>>    Without IDNA the client could send the query without knowing
>>    if the server supports UCS or not.

Yes, as Patrik says EDNS will result in the above.
But if you use UCS and EDNS you may get one additional query.
I know Dave do not think this is right, so I will try to give a quick
comment on why:
If you only allow IDN by having UCS aware servers, all clients
can send a query using either ACE or UCS and get the correct answer.
If you also allow IDNA servers, the IDNA servers can only give the
correct anser if the query is in ACE. This means that a UCS client
who want to send a UCS query, have to know if the server handles UCS
or not. If the answer is not, the UCS client have to send the query
using ACE. To test if the server can handle UCS, a separate query
must be sent. Here is the overhead.

>> 
>> 2) DNSSEC will probably be much more complex to handle due to
>>    having both ACE encoded and native UCS labels.
>> 

The complexity here is what I found out from my talk with Erik. You
might get away from most of it. In short this is because DNSSEC
signs RR-sets and with both UCS and ACE you have two representations
of the same label. The signing will be different depending on which you
use (unless you say signing should always be done on for example the
ACE form, but this looks wrong as an UCS client should never see
any records with ACE if they are sent from a UCS server).


   Dan