Subject: Re: Native UCS support in DNS versus IDNA

From: Dan Oscarsson <[email-masked]>
Date: Sun, 27 Jan 2002 14:19:10 +0100

>Taking your claim that you don'tever  want dual records for the same 
>underlying name it seems like there is two choices:
>1. IDNA forever - SIG records for the ACE-name records etc
>2. ACE-name record generated on the fly by server. No SIG records for
>   ACE-names.
>
>I agree with your argument that #1 is not the most efficient encoding of IDN
>names, but I think that #2 either will not happen in practise or that it
>will further delay DNSsec.
>Not happen at all because: I assume folks want IDN support tomorrow
>thus some zones want to do this without waiting for new DNS server software
>(and we can't prevent them from doing so).
>Thus they takes today's DNS server software and places ACE names in the zone.
>If the also see a benefit in providing DNSsec they sign the zone.
>Thus there would be some secure zones containing ACE names.
>How can they be conviced that they should drop the DNSsec (no more SIGs for the
>ACE names) for some better efficiency in the names over the wire?

I would expect that if you do the trouble of changing DNS server to get
DNSsec you could as well move to one that can handle UCS. UCS in DNS
server
is faire simple to implement, DNSsec is much more difficult.
There exists DNS servers handling native UCS today (for example the
nubind)
though not following any defined standard as there is none.
For me it would be much simpler to update my DNS server to handle UCS
than
to get all needed applications on my system to use IDNA.

But the world is not as simple as the two choices above.

IDNA defines that the labels that are "host names" are to be ACE
encoded.
So not all labels in IDNA are ACE encoded and the choice on which labels
are host names is up to the zone manager/applications.

By using native UCS in DNS all labels will use the same character
encoding (UTF-8).
This includes all the labels INDA do not encode or cannot represent as
its
does a conversion which destroys information before encoding into ACE.
An old (non-UCS aware client) will from a UCS aware server see the zone
as one
containg labels in ASCII, non-ASCII labels are converted into ACE.
DNSsec could treat the zone like that and sign it as that.
A new (UCS aware) client will from a UCS aware server see the zone as
one containg labels in UTF-8 and DNSsec could sign that. A UCS aware
client
should not get any ACE encoded labels from a UCS aware server (but it
may
get ACE labels from a IDNA server).
The DNS server here do not have to generate ACE on the fly, it can do it
when loading the zone.
But both forms should not be included in an answer. Then clients
would have to handle things like:
xxxxx IN PTR ucs-name.
xxxxx IN PTR ACE-name.
giving unnecessary complexity and is it acceptible for DNSsec that when
responding to "old" clients only use ACE records and when responding to
UCS clients with both?

For me it feels like a client should only see one format. Otherwise the
client have to spend time identifying which represent the same record
and
should be treated as one.
Of course one way to go could be to treat the IDNA world as totally
separate from the UCS world and have the UCS world be invisible for the
"old" ASCII world (by not doing conversion to ACE and not returning any
records with non-ASCII in).

So where should we go?
IDNA only,
IDNA plus ACE encoding everything else in non-ASCII,
native UCS in DNS with or without ACE to support the old world,
or something else.

Currently I have a strong feeling that DNS is going from the clear
simple service to something very complex, CPU expensive and
unfullfilling.

   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: Mon, 28 Jan 2002 12:36:42 +0100 (CET)

> to get all needed applications on my system to use IDNA.

You need to update all the applications to do some form
of unicode normalization in any case.
Otherwise you need gazillion SIG records to capture all the un-normalized 
Unicode variants that normalize to the same thing.

For existing applications (as opposed to potential new "IDN only"
applications) you also need to update them to be able to interoperate
with non-IDN aware peers.

So it's impossible to avoid upgrading the applications. Full stop.

> are host names is up to the zone manager/applications.

To the extent that much of the discussion has  been about host names
(with the syntax restricted by the applications) I agree that there
needs to be more discussion about other domain names such as the
allowed syntax for Internationalized mailbox names (or whatever they are 
called).
In such a case it might be sufficient to just do some well-chosen unicode 
normalization then ACE encoding i.e. no need to prohibit "dot-like" and
"space-like" characters as needs to be done for host names.

> should be treated as one.

There is complexity here due to caching in the DNS.
A cache either needs to have the whole RRset or none of it.
Thus the server can't choose to return a subset of the RRset as you
propose. Also, the SIG is for the RRset and not for an individual RR.

   Erik