Architectural issues involving Sitefinder & related functions

Tue Oct 7 05:25:37 UTC 2003

(since I haven't gotten back my enrollment confirmation, it seemed 
appropriate to crosspost this to NANOG.  While I will address 
Sitefinder, there are broader architectural and operational issues).

Let me assume, for the sake of this discussion, that Sitefinder is an 
ideal tool for the Web user, helping with the problem of 
not-quite-correct URLs.  Given that, I'll stipulate in this 
discussion that the implementation of Sitefinder, along with the .com 
and .net wildcards that lead to it for unresolved domains, is a true 
benefit for the Web user.

The Internet, however, is more than the World-Wide Web. It seems only 
logical to be able to discuss Sitefinder in two contexts:

       1. Where it becomes the default, as with the recent Verisign
          wildcards

       2. Where it is reached in some other manner.

My architectural concern is defining a way in which context #1 serves 
the _non-Web_ services of the Internet.  If DNS were purely an 
information service for Web users, the architectural conflict would 
go away, and only commercial and policy issues remain.

I would hope that within the scope of the Sitefinder discussion list, 
or alternatively in another forum, is an approach to reconciling the 
IP-level DNS such that it continues to serve non-Web applications.

Is there disagreement that Sitefinder provides no functionality to 
SMTP trying to deliver to an unresolved domain? To a user who 
mistypes the name of an FTP site and does not intend to use a Web 
browser?

What about failover schemes for non-HTTP cooperative research across 
the Internet, where the inability to resolve a host name (assume that 
cached records have a zero lifetime) triggers selection of an 
alternate server?

Seriously, technical people at Verisign may have thought about this 
and actually have suggestions. They may be very good ones, but, 
judging on the reactions to the Sitefinder deployment, it might be 
well to discuss them in open technical forums before a change is made.

I'm really not trying to make it a matter of personalities, but there 
have been public statements by Verisign executives that such a 
process inhibits innovation.  If Verisign policy is that as operator 
of .com and .net, it has the right to make unilateral changes, I 
think that needs to be clear to all concerned. I recognize that a 
number of independent parties suggest that the ICANN contract does 
not explicitly prohibit such unilateral action.

Ironically, I worked with the original founders of Network Solutions, 
and almost was a principal back when it was a couple of rooms in 
McLean. Gary Desler, the founder  and a fine engineer, always used to 
say "there is no technical solution to a management problem".  In the 
current context, I simply want to know the rules for the playing 
field.