Subject: Re: Native UCS support in DNS versus IDNA

From: Dan Oscarsson <[email-masked]>
Date: Tue, 22 Jan 2002 18:16:29 +0100

Erik Nordmark wrote:

>I should really ask for the name of your Internet-Draft since I suspect
>that the issues are a bit too complex to understand from an email >exchange.

>How is your idea different than draft-hall-dm-idns-00.txt?
>They sound rather similar.
My current draft is called: draft-ietf-idn-udns-03.txt
and is quite like Eric's. It has also changed several times.

In short I think you could say that to let the server
know if the client can handle UCS, it has to inform the server
in some way. My original ideas was to use the last unassigned flag bit
in the query header because this would allow non-ASCII to be handled
without having to add EDNS. Later versions have switched to EDNS
even though I still think using the last free bit is nicest at gives
least overhead.
When a server got a request from a client indicating it understands
UCS, it will give the answer in UCS. Otherwise it will ACE encode
the answer so that it can be handled by clients unable to handle
non-ASCII.
This will work fine as long as all servers handling zones with
non-ASCII characters are of the above UCS understanding type.
But as IDNA is defined, it allowes servers only understanding
ASCII to serve domain with non-ASCII by having its zone
loaded with the ACE-encoded form of a name. These servers will
not match a lookup for a name coming in using UCS.
It will therefore force the client to first identify if the server
can handle UCS, and then either send the query using UCS if it
can handle it or use ACE if not. Without IDNA the client need not
know if the server can handle UCS, if can just send away the
query. So with IDNA a client wanting to use UCS will have
to do two queries, one to test if the server understands UCS and
one to send the query. It some cases this can be combined, but
you will get an overhead for many years forward, especially
if what the IDNA people says is true: that it will be a long time
before a significant amount of the current DNS servers are upgraded.

>Does the above "response with ACE encoded labels" imply that the
>server has both an ACE record and a UTF-8 record in the zone file for >the same
>actual name?
As I would expect it, a UCS aware server will have all labels
in UTF-8 (or UCS) internally. Only one format. Conversion to ACE
will only be done when sending answers to old non-UCS aware clients.
>If not, how does this work with DNSSEC and offline keys for signing the >zone?
I think DNSSEC will have to enhanced with how to handle non-ASCII.
Basically sorting now is defined on the same base as matching:
case-insensitivity by making all lower case, the same can be applied
on UCS but more letters will be changed before sorting. I have not
looked at the rules for signing and how offline signing is done,
but it is not much different when using UCS. All you have to agree
on is to do it on the same format. When you include non-ASCII,
the data should be in native format (UCS-4 or in UTF-8), not some
encoded form like ACE.
ACE is for backward compatibility. I would not expect servers doing
DNSSEC to be that ancient.

   Dan

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jan 2002 19:15:36 +0100 (CET)

> >If not, how does this work with DNSSEC and offline keys for signing the
> >zone?

Why? DNS can handle any string of bytes including DNSsec.

> on UCS but more letters will be changed before sorting. 

The fact that DNSsec requires an order (what you call "sorting") 
is irrelevant. An order based on the byte values in a string of bytes 
is sufficient to have NXT be well-defined.

> I have not

That isn't the point. If you allow offline signing (or even if you have the
key online but don't want to sign ACE records on the fly) you need the zone
to have a SIG record for both the UTF-8 name and the ACE name.
Since SIG records are significantly larger than e.g. A/AAAA records
you are not saving much space by having the ACE A/AAAA record to be generated
on the fly.
Thus it seems just as simple to say that the zone contains
	<ace-name>	IN	A 1.2.3.4
	<utf-8-name>	IN	A 1.2.3.4
	<ace-name>	IN	SIG ...
	<utf-8-name>	IN	SIG ...
It is true that the first record above can be generated on the fly, but
it doesn't save much space when the records are signed.

  Erik