Re: [alac] Redirection of non-existing domain names, again

[Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>]

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.