Its so great to at least have some response. ;-)
I have said that there will be holes in my initial proposal, but this is a
good start. Lets work on ironing out the pathway.
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".
The assumption is no different than assuming clients will upgrade to ACE.
If we can assume that clients will be willing to upgrade to IDN then, there
is no reason to think that implementations would not include both ACE and
IDN(UTF8)/EDNS if IDN so specifies.
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?
This is an application implementation issue, NOT a protocol issue. If BIND
doesnt implement it well, there will be other software vendors that will
make it work as "specified".
- 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....
I dont understand. If you do a dig with any non-upgraded clients, then you
will be only digging for English domains. If you are using an upgraded
client then you will be able to parse the packet. Also, for most cases I
would imagine it will still fit in one packet.
What happens to an ACE-based client that receives an EDNS response that
it's
not able to parse?
That, as specified in 1. is not possible. ALL ACE implementations MUST also
implement IDN/EDNS. That is why the discussion should start NOW! Finally
someone realizes my point on why we need to discuss this now and not after
we have done the ACE part :-)
- 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....
I see your point. What if ACE requests will receive only ACE results, while
UDNA requests will get both the ACE and the UTF result. This way, we know
for sure that the inquirer knows UDNA if they initiated it first.
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..
Not much slower than what you should expect if you go for "ACE everywhere"
- 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...
First of all, the EDNS migration path will be expected. Then, if the
Zimbabwe DNS operator wishes to offer IDNs, they would upgrade to IDN/EDNS.
If they do not provide IDN resolution service, then IDNs wont work anyway.
- 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...
Clients that do not upgrade will eventually be obsoleted. At least we know
that. Also, if the admin is so desparate to know what the ACE is, s/he
could always use other conversion tools to view it. But as the core app,
ACE need not be done. That's the beauty of ACE, isnt it?
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....
Precisely why we should plan ahead better this time.
Edmon