-------- Original Message --------
Subject: Re: [Politech] PFF's Bill Atkinson: ICANN is "out of control, " VeriSign harmed
Date: Wed, 08 Sep 2004 16:36:12 -0700
From: Bill Stewart <[EMAIL PROTECTED]>
To: Declan McCullagh <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Declan - Of course ICANN is out of control - it has been almost since the beginning, but part of the reason it was created was that Network Solutions had been radically out of control. In this particular case, ICANN decided to do the right thing*, because Verisign's actions were seriously breaking the Internet.
Atkinson's article complains about ICANN interfering with
Verisign's Sitefinder, which broke significant DNS and Internet functionality
without discussing it with the public first,
and Verisign's proposals for international domain names,
which are extremely complex and also appear to break DNS and Internet
functionality in similar ways,
and also complains about ICANN interfering with Verisign's
registry business activities regarding domain name expiration
(which I have no technical opinions on, but they do appear to be
within the range of things ICANN should expect a subcontractor to
handle better than they did.)
Most of the problem ranges from Verisign saying "If we change _X_, we can build useful web services", forgetting that DNS's job is to support the entire Internet, including email, instant messaging, games, secure web connections, file transfer, file systems, and various login protocols in addition to simple non-secure web pages, and trying to use their centralized position to build centralized services they can dominate, when the natural functional layering of the Internet tools leads to decentralized services. Verisign's Internationalized Domain Name support uses a very similar approach, and breaks many of the same things, in even more complicated ways.
For instance, when you type a nonexistent domain name into a Microsoft web browser, it looks up the name in DNS, the DNS server says "that name doesn't exist", and the browser looks up the name you typed in a search engine to find something similar. Usually it picks MS's own search engine, but you can set it to look in Google or whatever else you want, including a Verisign search engine if they offer one. Sitefinder hijacked this process, setting their DNS server to return the address of Verisign's search engine instead of saying it didn't exist.
- If you were just looking up a web page you'd seen on a billboard, Verisign's hijacking reduced your choice of search engines but wasn't a major problem - but if you were trying to set up a secure web connection to your bank and mistyped the name, your browser will try to set up a secure connection to Verisign, which isn't your bank, instead of giving you an error message. That could be a real security and privacy problem.
- If you were trying to send an instant message, Verisign still gives you the address of their web search server, which isn't running your instant messaging protocol, so your IM client tries to connect and fails, instead of telling you that's the wrong IM server.
- If you're trying to send email, it's far more broken,
because Verisign tried to do a half-baked job of it.
Normally, your email client or server looks up the address you typed,
DNS says it doesn't exist, and the client tells you to try again.
But Verisign's hijacked DNS would tell you the address of Verisign's web
server,
so your mail client would hand the message to your office or ISP's server,
which would try to email it to Verisign, which had a stub email server
that rejected your message, and a couple hours later your mail server
would give up and send you a "couldn't deliver your mail" message
which you probably stopped reading several virus epidemics ago,
and you'd never know that your mail to xeample-client.com didn't get delivered.
Verisign changed their mail server a bit after a couple days of complaints,
resulting in slightly better error messages, but that says that they
not only didn't discuss their plans with the Internet community
before deploying them, they also didn't test their server design first.
- Another email problem was that they broke many spam blockers. Spammers keep changing their tricks, and one trick they used was to send mail claiming to be from nonexistent domains so it was hard to complain to their real ISP about it. So one popular spam-blocking tool was to check if the email or its envelope came from a valid domain name, and reject it if it didn't. But Verisign told their DNS to respond with the IP address for their web server instead of saying the name didn't exist, so this kind of spam could leak through. It wasn't a huge problem - there were lots of different kinds of spam, and you could work around it by telling your email system that Verisign's IP addresses were spammers, but it was yet another annoyance that indicated they'd done very little testing before breaking a major Internet protocol.
Verisign's Internationalized Domain Name support proposals are trying to address a real issue, which is the need to support domain names that aren't just US English 7-bit ASCII, including domains in European languages that need accent marks, domains from Japan and India using different alphabets, domains from China using ideograms, etc. Fortunately, they've spent a long time trying to talk other people into accepting their proposals, because it's a difficult problem that requires cooperation from lots of different kinds of software. Unfortunately, their proposed solution is not only complex, but it uses may of the same half-baked web-centric approaches that their Sitefinder DNS hijack used, and really isn't fixable, and ICANN did the right thing* by not encouraging them.
[* There! You've seen me write "ICANN did the right thing" twice in the same email message! It's not a phrase that I'd normally be inclined to use, because I usually disagree with them, but it's definitely true here.]
---- Bill Stewart [EMAIL PROTECTED]
_______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/)