I have been attending the Icann conference in Malaysia this week. One of the key events was the submission of the report – ssac-report-09jul04.pdf – from the Security & Stability Advisory Committee regarding SiteFinder.
In reading the committee’s report I discovered what I believe is an incredible breakdown in logic and as a consequence, a very mistaken, or at least confused, set of conclusions. So, why do I say that?
VeriSign’s SiteFinder service effectively took a large number of non-existent domain names and “turned them on” through the use of a wildcard in the .com and .net root zones. Instead of “domain name not found” the names were treated as valid domain names and (for those protocols not dealt with by VeriSign) applications seeking to bind to the relevant protocol received protocol level errors.
The security and stability report claims that domain names that are active, but for which many protocols are not live, break the end to end principle of the Internet.
So here is my point. The 63 million owned domains rarely have active support for most protocols. Most do not even have a web site using the http protocol. All that VeriSign’s SiteFinder did was to turn many more domains into the equivalent of “live domains”, in other words ones which behave like many of the 63 million domains already active. Just like real domains they became live but did not support all protocols.
If SiteFinder breaks the Internet in any way, it certainly is the case that normal domain name practice also does this.
The proof of the fallacy in the Security and Stability report is best given through an example. Let’s say I could buy the error logs from the root servers and discover the domains that I would need to buy in order to recreate the equivalent of SiteFinder. I then bought those domains and pointed them all to my new search engine, but left all other protocols inactive. I would have legitimate ownership of the names, but all of the criticisms of SiteFinder’s negative consequences for applications would be still true. The same end result, but through purchase rather than through a wild card. Nobody could stop me buying those domains and doing as I like with them. But nothing would have improved in terms of the Security and Stability of the internet compared to a wildcard implementation.
What does this all mean?
It means that SiteFinder doesn’t break anything that is not already broken with normal practice by domain name owners today. To single SiteFinder out, and not also criticize all domains that do not enable all protocols is a very obvious error. There is actually no difference between the two from the point of view of the application. Normal domains do not return “domain does not exist”. If they are in the DNS but not running protocols then the application returns an error at the protocol api level due to a failure to bind to the required protocol, just as with SiteFinder. Arguably, because of VeriSign’s efforts to deal with some of the more popular protocols, SiteFinder was a rather more stable environment than normal domain names, which often only implement http.
Hope that clarifies. I’m pleased to say that Steve Crocker told me afterwards that “I get points for figuring this out”. It seems to be a rather enormous discovery given the fuss SiteFinder caused. Steve Crocker wouldn’t, I’m sure, agree with this, but I think it entirely invalidates the committees findings.
Leave a Reply