Subject: Flagging non-ASCII in domain names

From: Dan Oscarsson <[email-masked]>
Date: Mon, 14 Aug 2000 08:47:10 +0200 (MEST)

To be able to support non-ASCII in domain names in a non-disruptive way,
the DNS server need to identify if a query is from the "old world" assuming
ASCII only or the "new world" that can handle non-ASCII.

Some think that EDNS is the way to do it, but that has one major
difficulty: a very big overhead! The "old world" servers will
return a failure when queried using EDNS resulting in the client
to have to retry the query without EDNS. And the client have to
use EDNS in every query, so this overhead will occur for every query.
The overhead can be reduced somewhat by using recusive queries and having
servers caching that state on other servers, but we can still expect a
lot of extra traffic.

In my draft I have several possibilities (ordered from best to worst):

1) The best way is to use the last unused flag bit in the header.

2) Another way is to use one of the flags bits that only have a
meaning in a response (in the old world). Like the RA, AA or TC bit.

3) Using the RCODE bits (they are only used in responses in the old world).

4) Using parts of QTYPE or EDNS. (will give error responses from old world).

The need to handle non-ASCII has existed since DNS was introduced and
it is very important for a lot of people. It must be possible to use
immediately without any large overhead compared to using ASCII only.
While DNSSEC will take many years before it really is used, using
non-ASCII in domain names will take off immedately (and is already being
tried live in DNS).

Therefore I do not think 4) above is no acceptible due to the overhead.

What do you think?

I have included some more comments about the above possibilities in my
draft: draft-ietf-idn-udns-00.txt

    Dan

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

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 15 Aug 2000 22:16:19 -0700

Dan,

> difficulty: a very big overhead! 

Yes, but...

So far, the IPNG and DNSEXT working groups look like they'll be making
the use of EDNS mandatory for IPv6 and DNSSEC (respectively).  As such,
it would appear that in order to work and play well in the future
support for EDNS is necessary.

> The "old world" servers will
> to have to retry the query without EDNS. 

As I believe I mentioned previously, the only EDNS-using resolver that
I'm aware of (the one in BINDv9) maintains state about the servers that
it has talked to regarding that server's support for EDNS.  That
implementation is openly available with a BSD-like license encouraging
use / modification / copying / etc. with essentially no restriction. 
Assuming history repeats itself and the Unix vendors (who in part paid
for the development of BINDv9) ship BIND as their default name server
and that the folks at Microsoft implement similar state-keeping, it is
likely that the number of retransmits due to lack of EDNS support will
be minimized.

> immediately without any large overhead compared to using ASCII only.

Well, as per the spec, the BINDv9 client tries EDNS0 requests first,
then falls back to non-EDNS0 if it receives a FORMERR (or lack of
response), so for those that use BINDv9 or other EDNS supporting
clients, using a server that does not support EDNS will result in worse
overhead than using a server that does support EDNS.  

Rgds,
-drc