Re: [alac] Redirection of non-existing domain names, again
Here's an updated draft that takes into account today's developments: - The service has gone live now -- kind of: The redirection server is unreachable from here, turning unregistered domain names into TCP timeout problems, and leading to an absolutely horrible user experience when typos happen. - Verisign got the TTL of the records returned right, so the issue about poisoning caches is only a problem for 15 minutes -- that's probably tolerable. - Verisign does *not* make use of the registry zone file for offering corrections, it seems, so our speculations on how such a service could be implemented in a competition-friendly and technically clean manner are moot. Regards, -- Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> At-Large Advisory Committee: http://alac.info/ The At-Large Advisory Committee is deeply concerned by Verisign's surprising roll-out of the "SiteFinder" service for .net, and the apparently imminent roll-out of that service for .com. SiteFinder works by re-directing queries for non-existing domain names to the IP address of a search service that is being run by Verisign. This practice raises grave technical concerns, as it de facto removes error diagnostics from the DNS protocol, and replaces them by an error handling method that is tailored for HTTP, which is just one of the many Internet protocols that make use of the DNS. We will leave it for others to explain the details of these concerns, but note that returning resource records in a way which is countrary to the very design of the DNS certainly does not promote the stability of the Internet. These concerns are not mitigated by Verisign's efforts to work around the consequences of breaking the Internet's design on a service-by-service basis, in particular since the work-arounds deployed depend on the global reachability of Verisign's redirection infrastructure. That infrastructure has already become unreachable few hours after the service was initially deployed, confronting Internet users with misleading network timeout error messages instead of quickly-delivered and accurate "no such domain name" errors. When working as intended, the service centralizes error handling decisions at the registry that are rightly made in application software run on users' computers. Users are deprived of the opportunity to chose those error handling strategies best suited for their needs, by chosing appropriate products available on a competitive marketplace. Software makers are deprived of the opportunity to compete by developing innovative tools that best match the user's needs. We would recommend that the board take whatever steps are necessary to stop this service.