(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 > requests 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 > response 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 > responses 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 the user.... > 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 > upgrade 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... > 4. IDN(UTF8)/EDNS > - 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.... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Attachment:
pgp00009.pgp
Description: PGP signature