(trimming main IETF list off the cc:)
On Tue, 02 Apr 2002 10:29:00 EST, Edmon Chung said:
1. IDNA clients
- the client does ACE and display it properly for the user
- servers (including DNS and mail and http, etc.) does NOT upgrade for
ACE. Even administration side is kept as is, allowing leakage
- IDNA clients MUST also be able to decode IDN(UTF8)/EDNS responses
This makes the rather rash assumption that the clients will be upgraded
to support a *future* feature. You're also assuming that there will be
a way to test/debug IDN/EDNS responses when there are none actually being
seen "in the wild".
Re-work the model, assuming that (a) 50% of the people won't upgrade until
the new feature is *usable*, (b) 10% of the clients *wont* upgrade, and
(c) there will be at least 2 or 3 show-stopper bugs found in the EDNS
handling when it starts being widely used.
You'll never get widespread deployment of a feature that is both not usable
and untested (because there's no use of it).
2. IDN(UTF8)/EDNS DNS Server upgrade
- DNS servers will now accept both ACE (as usual) and IDN(UTF8)/EDNS
Are there any hidden gotchas here? Are there any changes needed to BIND
to allow it to process a UTF8 zone file? Are there any "bad news" characters
that might cause parsing problems?
Again - what happens if not everybody upgrades?
- ACE requests will yield Both an ACE response + an IDN(UTF8)/EDNS
Here there be dragons. Do a 'dig aol.com mx', and ask yourself what
happens to performance if that doesn't fit into one DNS packet anymore,
and as a result a resolver has to drop back to TCP (instead of one packet
each way, you're now up to a 3-packet handshake, the data, and the FIN
packets) - and note that the TTL on the AOL.COM SOA is 3600....
What happens to an ACE-based client that receives an EDNS response that it's
not able to parse?
- IDNA clients continue to send in ACE but will start to see UDNA
This is a can of worms - how does the server know for sure that the client
is upgraded and is able to parse a UDNA response? Remember - the client
is probably *NOT* asking directly. If I've upgraded example.com's DNS
to be UDNA ready, how do I know it's safe to send a UDNA response to a query
from foo-bar.com (since it's quite possible that the *USER* has upgraded,
but the sysadmins have NOT upgraded the DNS that's recursing the query for
3. IDN(UTF8)/EDNS for clients & everywhere
- IDNA clients begin to obsolete, new versions of application software
comes with IDN(UTF8)/EDNS built in.
Which will be slower than you might think..
- In case DNS servers are not upgraded yet, clients will continue to use
the IDNA client, thereby also creating an incentive for server side to
OK.. How does my client tell that a DNS server in Zimbabwe is or is not
upgraded? Remember - DNS is *distributed*, and just because YOUR DNS
server is upgraded doesn't mean that the one actually providing an
authoritative answer has been upgraded...
- Other applications/servers upgrade to IDN(UTF8)/EDNS to accept UTF8
domains, administrators might continue to see ACE leakage if the client
still uses IDNA to send requests, but UDNA requests will be managed in UTF8
It's this "might continue to see ACE leakage" that's a major problem...
- Slowly but certainly, we will move towards full UTF8 because
administrators will likely want to deal with UTF8 than ACE, especially for
say those admins in China who are dealing with IDNs frequently. Added to
the urge from the user community to upgrade the server as they upgrade their
clients to IDN(UTF8)/EDNS.
Just remember the pain felt by *both* 50%s when 50% of the users had
MIME-aware MUAs, and 50% didnt....
Computer Systems Senior Engineer
Description: PGP signature