Re: [idn] impacted systems investigation

[Bruce Thomson]

It is presumably within the group's charter to do this, and it is probably a good idea to do such an investigation. On the other hand, we should consider whether the definitive results would have to be in before the standard is created. Every new protocol or platform inevitably requires bringing people up to speed. I myself have spent more time than I would like to admit making things multilingual that previously were not, or worse, rewriting apps and drivers for the latest version of Windows or the latest SCSI spec. Everyone expects to have to do some work to take advantage of the latest new technology. If I want to connect my digital camera to my computer with USB, I have to get a computer that was made in the last couple years with the right hardware, and then I have to upgrade to at least Win98 OSR2. People who are not in a hurry with this can wait. No big deal. In the idn case, the biggest concern probably is whether we will somehow melt down the entire DNS infrastructure by choosing an inappropriate encoding. Here is my analysis on that: There are basically 3 main classifications of DNS servers. I would not like any of the 3 to break... RACE encodings of course will not break the DNS, but what about UTF-8? 1) Authoritative servers. These are set up by domain hosting services and have to have records in local files for the domains they host. These servers need to actually respond with data for their local database when interrogated with UTF-8. If someone had an old version of BIND, this might not work, but anyone who is actively hosting idns would naturally upgrade. I am currently hosting domains that can be accessed with UTF-8, using BIND 8.2.3. Works with no problems, except the log entries are not readable. There is a patch available for this, which I am not using. Also, the .cc DNS is authoritative for .cc domains and answers queries in UTF-8. They have been going fine for some time with no apparent problems. 2) Root servers If someone types an idn but mistypes .com, his request would go to the root server full of UTF-8. Would this break something? But again, .cc domains are in wide use, and UTF-8 requests do get sent in large numbers to the root without any damage that I have heard of. 3) Caching servers Suppose I as a user want to resolve an idn, but my ISP's caching server stands between me and the authoritative and root servers. Will my ISP's BIND version cause me to be unable to resolve the idn? Or will I crash his DNS? This is by far the most important area for concern, because there are many versions out there, and we can't just stop the whole Internet and demand massive upgrades. Y2K all over again! :P But, in actual fact, BIND 8.2.3 works just fine here. Most ISPs are using it already. How do I know this? Because www.redhat.com and CERT, etc. have issued security advisories urging everyone to immediate update. There is a horrific security hole in previous versions that allows hackers to get root access on the DNS, and/or crash it. My site was actually a victim of this, and our DNS crashed about twice a day for over a week until we figured it out and upgraded. Therefore, any ISP who is so out of it as not to have upgraded has much more serious problems than whether idns work, or perhaps crash him. In this case, let's just distribute the word on those old, bad versions: "ISC has discovered or has been notified of several bugs which can result in vulnerabilities of varying levels of severity in BIND as distributed by ISC. Upgrading to BIND version 9.1 is strongly recommended. If that is not possible for your site, upgrading at least to BIND version 8.2.3 is imperative." Sendmail was also discussed as the source of possible problems. This problem can be eliminated by suggesting that idns not be used in e-mail communications except within the intended country. (see my previous post.) Bruce ----- Original Message ----- From: "Marc Tamsky" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 09, 2001 1:32 PM Subject: [idn] impacted systems investigation > > Is it outside the scope of this group's charter to start discussing > the formation of a detailed list of existing systems (whether > software, hardware, or protocols), and > a) how they are affected by each of the proposals > b) how difficult updates or upgrades are for each > c) the time frame for announced upgrades > d) the attrition rate for legacy systems > e) the growth rate for that class of systems, and how soon newer > systems will become the majority of used systems > > My interpretation of discussions that happen on this list -- the > careful, methodical, as-scientific-as-possible review of the changes > proposed within this group have been discouraged at every possible > opportunity. > > All the proposals involve significant changes to many systems. > > The fact that no work has been done to quantify those changes should > raise alarm bells -- the work to quantify the number of affected > systems is large -- without any work to quantify it, perhaps very > large. > > The changes needed by other systems is STRICTLY larger than the work > to come up with the estimates of work. > > Comments? > > Marc. > >