Subject: Native UCS support in DNS versus IDNA

From: Dan Oscarsson <[email-masked]>
Date: Sun, 20 Jan 2002 17:19:28 +0100

As the DNSEXT group have many experts on DNS I would like your
comments on the following.

As you may know the IDN working group is working on how to
be able to use domain names with non-ASCII characters, often
called IDNs. This has resulted in a way to encode
IDNs into ASCII using an ASCII Compatible Encoding (ACE) to
make it possible for old software only expecting ASCII, to
be able to access IDNs. And two main solutions to how DNS
should work:
1) The IDNA solution. This does not modify the DNS protocol
   and does not require anything new from the DNS servers.
   In this the client converts the domain name into a
   case and form insensitive format and encodes it with an
   ACE. The client send sends the query into DNS.
   DNS servers handling IDNs have their domains loaded
   with the same ACE encoded case and form insensitive format
   of the name and need only do a binary compare.
   Only lables corresponding to "host names" are encoded.
   Other lables of character fileds in RRs are not
   handled.
   
2) The native UCS solution. This requires modification to the
   DNS protocol to be able to support non-IDN servers and clients
   with ACE encoded names, and modified servers.
   It uses UCS in the form of UTF-8 in lables and all other
   character data fields, but will respond with ACE encoded
   lables when the query is from a client that only understands
   ASCII. This fallback is like what the IDNA solution is using.

I belong to those who think a native solution is better than a
solution layered on top of DNS by encoding things into ASCII.

As the IDNA has a single solution (there are several not yet
fully ready native versions) it currently looks like it will
be moved to RFC status soon, I have tried to see what IDNA
would mean for a domain and if it would affect a native solution
introduced later.
I then found out that by allowing the IDNA solutions now, a native
solution will require that many queries will have to be retried,
once using native UCS and once using ACE. If effect doubling the
calls done between client and server. This can be somewhat
reduced by caching the failed 1:st try, just like you can
cache if a server understands EDNS or not. Also, to reduce
traffic, you cannot just use a flag bit to tell the server
if the client understands native UCS, as this may be cleared
on the way to the server, instead you have to use a protocol
extension that will result in query failure.

To show this I have tried to below show different cases.
I have for some hours tried to get something you can understand,
I hope you can.

What I try to show is that, in the case where we allow the IDNA
solution with unmodified servers having ACE encoded names, a future
native UCS solution will require more retries and caching of
state to reduce the overhead of retries.
But if we only allow a native solution, it will work much
simpler and get no overhead (except if EDNS is used, but then the
EDNS state is the same as for all other EDNS requests) and
it will work with both IDNA clients, all current clients and new
native UCS clients.

In my cases below, I show different cases with different clients
and servers. First by direct connection between client to
server and then with a intermediate server.
For the UCS client cases I show the difference between
using a flag indicating UCS awareness using a flag bit in
the standard header or using a flag bit in the EDNS OPT RR.
As said above, to reduce overhead, a flag bit will probably not be
good enough if IDNA servers are allowed, instead an extension
like a new label type which will result in call failure for both
old a new EDNS servers may be required. I have not included
what that may change because it will still result in nearly
the same retries.

Observer the difference when no IDNA servers are allowed.
Please correct my cases or show that my thinking is wrong.

After all this and after you have studied this, my questions
to you are:

- Should DNS natively handle non-ASCII character data?

- If the answer to the above question is yes, and my analysis
  that IDNA will result in a native solution being more complex
  and requiring more overhead, is it acceptible that IDNA
  as it is defined today, is allowed?
  From what I can see, once IDNA is allowed, native handling
  of non-ASCII in DNS itself will never be easy.

    Dan Oscarsson

Cases below.

Definitions
 ADNS-SERVER    - a server with no UCS support and only ASCII domain
names
                  and there exists no IDNA servers in the world
 IDNA-CLIENT    - a client doing IDNA queries (ACE encoded domain names)
 IDNA-SERVER    - a UCS unaware DNS server having ACE encoded domain
names
                  or just ASCII domain names, when IDNA is allowed
 UCS-CLIENT     - a client doing native UCS queries or ACE encoded
queries
 UCS-SERVER     - a UCS aware DNS server having all data in UCS. Can
                   answer both using native UCS or ACE encoded labels.

 IDNA-CLIENT(ACE) a IDNA client looking for non-ASCII domain name using
ACE
 UCS-CLIENT(ACE)  a UCS client looking for non-ASCII domain name using
ACE
 UCS-CLIENT(UCS)  a UCS client looking for non-ASCII domain name using
UCS

Query cases showing call chain for client to server and response to
client
--------------------------------------------------------------------------
: Looking for a non-ASCII domain name with IDNA servers
Case: IDNA-SERVER, IDNA-CLIENT
  IDNA-CLIENT(ACE) -> IDNA-SERVER -> IDNA-CLIENT (found or not found)

Case: IDNA-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (not found) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found)

Case: IDNA-SERVER no EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR
  UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (failure EDNS) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found)

Case: IDNA-SERVER with EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR
  UCS-CLIENT(UCS) -> IDNA-SERVER -> UCS-CLIENT (not found) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> UCS-CLIENT (found or not found)

: Looking for a non-ASCII domain name with UCS servers
: and NO IDNA servers are allowed
Case: UCS-SERVER, IDNA-CLIENT
  IDNA-CLIENT(ACE) -> UCS-SERVER -> IDNA-CLIENT (found or not found)

Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-CLIENT (found or not found)

Case: UCS-SERVER, UCS-CLIENT, UCS flags in EDNS OPT RR
  UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-CLIENT (found or not found)

Case: ADNS-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (not found)

Case: ADNS-SERVER no EDNS, UCS-CLIENT, UCS flag in EDNS OPT RR
  UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (failure EDNS) need retry
  UCS-CLIENT(ACE) -> ADNS-SERVER -> UCS-CLIENT (not found)

Case: ADNS-SERVER with EDNS, UCS-CLIENT, UCS flag in EDNS OPT RR
  UCS-CLIENT(UCS) -> ADNS-SERVER -> UCS-CLIENT (not found)

Query cases showing call chain for client to server and response to
client
when there is a DNS server between client and final server
--------------------------------------------------------------------------
: Looking for a non-ASCII domain name with IDNA servers
Case: IDNA-SERVER, IDNA-CLIENT
  IDNA-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER 
  IDNA-CLIENT      <- IDNA-SERVER <-------!
  answer (found or not found)

Case: IDNA-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (not found) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer (found or not found)

Case: IDNA-SERVER no EDNS, UCS-CLIENT, UCS flags in EDNS OPT RR
  UCS-CLIENT(UCS) -> IDNA-SERVER
  UCS-CLIENT      <-------!
  answer: (failure EDNS) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (found or not found)

Case: IDNA-SERVER with EDNS, next without, UCS-CLIENT, UCS flags in EDNS
OPT RR
  UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (failure EDNS) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (found or not found)

Case: IDNA-SERVER with EDNS, next with EDNS, UCS-CLIENT,UCS flags in
EDNS OPT RR
  UCS-CLIENT(UCS) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (not found) need retry
  UCS-CLIENT(ACE) -> IDNA-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- IDNA-SERVER <-------!
  answer: (found or not found)

: Looking for a non-ASCII domain name with UCS servers
: and NO IDNA-SERVERS
Case: UCS-SERVER, IDNA-CLIENT
  IDNA-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER
  IDNA-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found)

Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found)

Case: UCS-SERVER, ADNS-SERVER, UCS-CLIENT, UCS flag in standard query
header
  UCS-CLIENT(UCS) -> UCS-SERVER -> ADNS-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (not found)

Cases with EDNS gets even more complex

: Looking for a non-ASCII domain name with UCS servers
: and also allow IDNA servers
Case: UCS-SERVER, IDNA-CLIENT
  IDNA-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER
  IDNA-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found)

Case: UCS-SERVER, UCS-CLIENT, UCS flag in standard query header
  UCS-CLIENT(UCS) -> UCS-SERVER -> UCS-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found),
  if not found => retry because an IDNA server may have answerd
  UCS-CLIENT(ACE) -> UCS-SERVER -> UCS-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found)

Case: UCS-SERVER, ADNS-SERVER, UCS-CLIENT, UCS flag in standard query
header
  UCS-CLIENT(UCS) -> UCS-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (not found) need retry
  UCS-CLIENT(ACE) -> UCS-SERVER -> IDNA-SERVER
  UCS-CLIENT      <- UCS-SERVER <------!
  answer: (found or not found)

Cases with EDNS gets even more complex

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 00:18:37 +0100 (CET)

>    ASCII. This fallback is like what the IDNA solution is using.

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.

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?
If not, how does this work with DNSSEC and offline keys for signing the zone?

   Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 21 Jan 2002 20:40:09 -0600

> They sound rather similar.

Actually, Dan had a draft out before mine.

I don't think he's talking about that approach however. He seems to be talking
about not tagging the labels via EDNS (apologies to Dan if this is incorrect),
which is not an approach that I advocate.

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

Not to steal Dan's thread, but since you brought these issues up, I've devised
a scheme for dealing with this and am incorporating it into the next version
of the draft, ETA next week.