Site Finder

Quoting Rusty Lewis from
http://verisign.com/corporate/news/2003/pr_20031007b.html?sl=070804

"We will continue to take feedback from both Internet users and the
technical community on how we can ensure that the service is available
for the many Internet users who clearly like it."

Well that's very simple Rusty - stop screwing around with *our* DNS and
write a plugin for IE to catch NXDOMAIN, just like the Google toolbar
does.

That'll allow 90% of the browsing population a *choice*, something the
wildcard clearly does not.

Ray

Yes, I will heartily agree with this. Having this functionality be
triggered by a wildcard in the DNS records is the wrong approach. It's
the application that should be taking care of this

if (NXDOMAIN)
  redirect(preferences->sitefinder_host, url);

If verisigin wants to partner with someone to actually host the
sitefinder site but have some switch integrated into like
IE/Netscape/whatever to use that site, I have no problem with this. It
becomes a choice of the individual user to use it and the rest of us
don't get screwed by something we have no control over.

I've been thinking that there should be a new type of
record introduced to be application specific for HTTP, just as
MX only applies to smtp.

  Due to a wide variety of applications relying upon A
records as their method, or method of last resort (eg: if no MX,
go directly to the IN A record) perhaps there needs to be some new
HTTP specific record introduced?

  This would allow anyone to add their own wildcard entries for their
own redirect services (eg: aol and microsoft could run their own on their
own nameservers) without impacting the alternate applications.

  This may be a bit late in the picture to apply this, but I'm
sure that the browser people (ms, aol/netscape, mozilla, apple/safari)
would be willing to do the minor additional coding work as it obviously
would mean the ability to redirect the ad revenue to their own services
easier if this were implemented, without all the other damage of intrudcing
flat-out A records in wildcarded zones to be used by the http protocol.

  - Jared

I've been thinking that there should be a new type of
record introduced to be application specific for HTTP, just as
MX only applies to smtp.

Correct me if I'm wrong, but this is basically what SRV records
(rfc2782) are intended for. They're not widely impemented by client
applications, however.

This would allow anyone to add their own wildcard entries for their
own redirect services (eg: aol and microsoft could run their own on their
own nameservers) without impacting the alternate applications.

I think you'd still have the issue of an NXDOMAIN not being returned;
i.e., if there's a wildcard, you won't get an NXDOMAIN response if
there's no A but there is some other record.

Quoting Rusty Lewis from
Newsroom - Verisign

"We will continue to take feedback from both Internet users and the
technical community on how we can ensure that the service is available
for the many Internet users who clearly like it."

Verisign is trying to move this argument into a question of what best serves the end-user. They are doing this because the public understands that, and because they know they can't win the question of what best serves the infrastructure providers. We're the ones who have to pay to make changes to deal with things they break.

I happen to think that the issue of serving end-users is irrelevant to the decision. But if they want to make it, then I think it is important that we make it clear to people what the *real* statistics are--not the ones that Verisign is carefully manipulating.

Keep in mind, when you see Verisign pushing user services, that the majority of the "benefit" they are providing is to users who already got that benefit from other companies. You don't get credit for providing a service when you just stole the customers from someone else. Especially when your technique for providing the service breaks other services.

"84 percent of Internet users who have tried Site Finder said that they preferred the service to receiving an error message."

If you look at IE market share (I've seen IE6 listed at 55-70%, IE5 at 13-32% and I believe both redirect NXDOMAIN errors, correct me if I'm wrong), and also figure in the AOL users, it appears that conservatively 75% of all users already had a SiteFinder-like service. They weren't seeing "an error message" and the above survey question is irrelevant. They were seeing Microsoft's or AOL's web pages.**

So, of the twenty million typos Verisign reports per day, only five million are "new" users, the rest they temporarily hijacked from Microsoft and AOL. And according to the Alexa stats reported on Cyberlaw, only 20% of the visitors actually used the service. So the number of new customers benefiting from Verisign's service is at most one million per day. Nothing to sneeze at, but a far cry from twenty million.

On the other hand, they claim that 68% of the connection attempts were from web browsers. If I've done my math correctly, that implies a total of 38.8 million connections, with (based on Versign's stats) 5.2 million email connections and 5.5 million connections from other applications. It is of course, hard to judge how many users, ISPs and companies were inconvenienced by those 10+ million misdirected connections, but it doesn't look to me like the cost/benefit ratio is nearly as big as Verisign is claiming.

Finally, since I'm on stats. Verisign is claiming that 3% of spam is dealt with by blocking bad domains. In the first place, that's nothing to sneeze at. Although Verisign claims that major spam filtering companies (they didn't ask us, so I guess that puts us in our place :slight_smile: don't rely on that service, the fact of the matter is that major ISPs do. A 5 second test shows that AOL uses it as a technique to bat away spam at the MAIL FROM line. And we all know that the sooner you can keep spam out, the better off you are. So, just using Verisign's stats, that means that AOL had to do additional spam filtering on 60 million messages a day (3% of 2 billion, which I believe is their current daily number). I don't know about you, but given the choice of turning away 60 million messages at the MAIL FROM, or accepting them and then filtering them, I know which I'll choose. I question the 3% number though. Others have reported that bad domains account for 11%. Spam percentages are notorious in varying greatly from site to site, but when I looked at somewhere.com's email from 04/2002 to 03/2003 I see 1.5 million messages rejected due to bad domains. That's 17% of the messages we rejected for that period.

** And I'm quite sure they'll go back to seeing browser-specific pages when new browsers are released. In fact it seems likely to me that *all* browser manufacturers are going to start providing similar services, now that Verisign's pointed out how lucrative it is. If web browsers start eating up Verisign market share, the question of countermeasures gets very interesting. Will they go quietly, or will we suffer through a fight?

Verisign is trying to move this argument into a question of what best

serves the end-user.<<

This doesn't matter, their point should be moot. Verisign is charged with
managing the .com and .net domains for the public. They DO NOT OWN those
domains so they are not allowed to use them for their own greedy purposes.

An example, some outfit gets charged with managing a government housing
development, so they decide to use the parking lot to hold their own private
flee market. It's not their property and they have no right to do this. Same
goes for whoever gets to manage .net and .com.

It's not about what's best for anyone, it's about improper use of public
property for personal gain.

Geo.

Hrm. Perhaps the way to answer that question is to figure out how much
cost of the extra mail processing etc is going to increase end user costs.

Ask the user "Are you willing to pay your ISP $1 more a month to deal with
verisign not dealing with the technical issues?"

I suspect the answer is a strong no.

Jason

Date: Thu, 16 Oct 2003 15:23:41 -0400
From: Kee Hinckley

Verisign is trying to move this argument into a question of what best
serves the end-user. They are doing this because the public
understands that, and because they know they can't win the question
of what best serves the infrastructure providers. We're the ones who
have to pay to make changes to deal with things they break.

I happen to think that the issue of serving end-users is irrelevant
to the decision. But if they want to make it, then I think it is

Good point. I think portable, globally-routable /32s would
greatly benefit end users. Does that mean $someone should push
for that?

Eddy (happy drawing the line at _multihomed_ /24 or so)

I agree that an application level solution at the edge is the best.

I like the idea of having a user configurable parameter in the client
browser to allow the ``finder'' URL to be set. The browser
``manufacturer'' would of course put their own default and the ISP would
be able to ``configure'' their own defaults and the
end user could ``change'' it to suit their preferences.

This would allow competing ``URL finder'' type services, allow ISPs to
fine tune the interface for their customers and allow end users to
customize their own interface to the ``web''.

Maybe its time for some ``finder'' API specifications,
mozilla patches, and ``finder'' reference implementations.

All of which would probably be off-topic for this forum. :slight_smile:

The Internet Explorer Administration Kit has enabled this functionality for many years. We changed our default search page to Google about 3 years ago for all of our users who install our branded IE and dialer CD.

-Robert

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey