VeriSign Mulls Way to Make Money from Typos

[silver]

from computerwire

VeriSign Inc is testing changes to its domain name system services, which could generate tens of millions in revenue a year for itself and partners, and which would impact the way almost every internet user surfs the web.

A VeriSign spokesperson confirmed yesterday that the company is internally testing a system whereby web domain name lookups in the .com and .net domains that would normally return error messages would instead return a web page.

Such a service was tested in May by NeuStar Inc, which runs .biz and .us. In Neustar's trial, instead of error messages web users received a search engine page provided by sponsored search provider LookSmart Ltd. VeriSign's test is similar.

"Like many registries, we're continually exploring ideas on how to enhance the user experience," the VeriSign spokesperson said, confirming a report in Friday's Wall Street Journal and declining further comment.

VeriSign operates the .com and .net domain name registries. When a user enters a URL from those domains into a web browser or email client, it is looked up in a DNS hierarchy that ends at VeriSign's authoritative servers.

Currently, VeriSign says it handles about nine billion DNS lookups per day. It is estimated that 800 million to 900 million queries result in an error message because the domain does not exist, often because the user has typed it incorrectly.

Ram Mohan, CTO of Afilias Ltd, which operates .info, said approximately 10% to 12% of queries to the .info registry infrastructure are misspelled or for non-existent domains. He said he believes VeriSign's .com and .net registry has a similar ratio.

Currently, the number of queries VeriSign handles has no direct bearing on how much revenue it generates, but if the company could find a way to monetize the error traffic, it could generate tens of millions of dollars every year.

NeuStar was the first major top-level domain (TLD) operator to try out such a service. In May, the company entered a trial with Paxfire Inc, a virtually unknown Washington DC-based "internet traffic brokerage" startup.

Paxfire's idea is to act as a middleman between search engine providers and companies that have the means to drive traffic to them, especially domain name registries, according to Paxfire CEO Alan Sullivan.

Sullivan said Paxfire, which expects to offer a hosted service that returns web pages instead of error messages, has seen interest from many search engine providers and TLD operators, particularly overseas companies offering country-code TLDs.

If VeriSign were to offer such a service, it would likely be of concern to Microsoft Corp and America Online Inc, which could stand to lose money, as well as the intellectual property lobby and advocates of adherence to internet standards.

A service where error messages are intercepted at the DNS level would usually override similar systems where errors are intercepted at the client (such as in Microsoft's Internet Explorer) or ISP (such as AOL's flagship online service).

Currently, both AOL and Microsoft intercept error traffic and instead redirect users to search engine pages they operate. Sometimes, this equates to a paid click. A Microsoft spokesperson told the WSJ that this revenue is a "non-trivial" amount.

It's difficult to determine exactly how much revenue VeriSign could create. Back-of-the-envelope calculations suggest that VeriSign could create revenue of $1m per day for itself and partners if it could convert 0.3% of its error messages into paid clicks.

That's based on estimates (from Afilias's Mohan) that VeriSign's .com and .net registry returns about 800 million error messages a day, and the average pay-per-click of $0.40 reported by paid search leader Overture Services Inc in the second quarter 2003.

Paxfire's Sullivan said that during the NeuStar test, users chose to query the LookSmart search engine they were presented with 35% of the time, but this may have been artificially high due to the novelty value.

It's difficult to say how many of those queries turned into a revenue event, Sullivan said. However, he estimates that registries could probably convert 0.1% of their error traffic into a paid click using Paxfire's service.

"It's found money," Afilias's Mohan said. He added that Afilias has no current plans to introduce a similar system under .info, but he did not rule it out.

Paxfire's Sullivan said: "You can be assured that if VeriSign does this, then everybody [every other registry] is doing this." Paxfire is not currently working with VeriSign, however, he said.

A spokesperson for LookSmart said that the NeuStar/Paxfire test never evolved into a formal deal. He said: "The whole positioning for LookSmart is to provide as much relevancy as possible, and those two deals were not in line with that strategy".

If VeriSign's plan gets beyond the test phase, it could hit some hurdles, particularly due to its contract with the Internet Corp for Assigned Names and Numbers, which manages aspects of the DNS under contract with the US government.

"It would probably be something we would need in the contract," said ICANN gTLD registry liaison Tina Dam. "At this time we don't know the details of the service, so I can't really say."

"Some organizations have shown a propensity to make technical changes happen and then ask for permission later," Afilias's Mohan said. "Given the economics of it, I think that's what will happen here."

There's also the suggestion that returning live web pages instead of error messages could break with the Internet Engineering Task Force standards on how DNS should work. Some say it's a "gray area".

Afilias's Mohan said that, according to standards, DNS registries have to be "unambiguous, authoritative and accurate". Under an error interception system "the accuracy of the response is in question".

Paxfire's Sullivan said his company's service is set up so that only web traffic returns an IP address. Domain queries for non-web applications such as email or FTP are dropped or return error messages, he said.

Lastly, VeriSign may have to be concerned with intellectual property interests. Some could claim that returning a VeriSign page when a user enters a misspelled trademark is not too dissimilar to cybersquatting. Others say it's no different than a search engine returning a similar result.

sounds like a bad idea to me...

Sil

[squidgy]

Sounds like it could pave the way for anti-trust action against Verisign too.

How exactly will it work? Does it mean that names which don't belong to anyone - such as doyouthinkanyonehasthoughtofthisnameyet.com - will resolve to IP addresses used to host VeriSign web sites, instead of not resolving at all?

A further complication. Just because a host name doesn't resolve to an IP address, doesn't mean to say that the domain name doesn't exist. Maybe the domain has an authoritative name server, but the owner has chosen not to assign it, or any of its subdomains, to any IP addresses. Is VeriSign able to do anything about that? If they can and do, then that would definitely open a can of worms.

[Ian]

It seems to have gone live, trying to browse non-existant domains redirects to a search page with adverts..

http://www.versign-are-chimps.com

which may or may not work depending on your dns servers.

[silver]

doesnt appear to work for me (at the moment at least) - I really think this kind of thing is pretty similar to domain hijacking..?

Sil

[silver]

actually - I think it did try and do it - I ended up at a url with

http://sitefinder.verisign.com/lpc?u...are-chimps.com

which I presume means it tried to work?

Sil

[squidgy]

http://www.doyouthinkanyonehasthoughtofthisnameyet.com - yep, it works.
http://www.i-cant-believe-verisign-w...ch-a-thing.com

I think this is big stuff. Do you reckon verisign's search portal might nick Google's crown? http://sitefinder.verisign.com/spc?sb=search - I notice that Google is the first non-sponsored result.

I think that sponsored links here completely changes the marketplace for domain registration. And it's not really fair on those who have already bought domains, too.

Where exactly do verisign get their search results from?

My prediction? Be surprised if you haven't seen anti-trust action within three months from now.

http://www.antitrust-action-against-verisign.com

Do you think they'll get the hint?

[squidgy]

http://64.94.110.11

We didn't find: "64.94.110.11"
There is no Web site at this address.

No - I don't suppose there is.

[squidgy]

There have been lots of talk of network administrators getting rather riled by this. Especially at http://slashdot.org/articles/03/09/1...&tid=98&tid=99

This will have the immediate effect of making network trouble-shooting much more difficult. Before, a mis-typed domain name in an email address, web browser, or other network configuration item would result in an obvious error message. You might not have known what to do about it, but at least you knew something was wrong. Now, though, you will have to guess. Every time.

Umm - I think that's overstating things a bit.

So I ran my port scanner against 64.94.110.11 ports 1 through to 1023 (I think my ISP can make an exception to the "no port scanning" rule in this case). The only open ports were 25 (smtp) and 80 (http).

Some have pointed out that this will make an important anti-spam check impossible. A common anti-spam measure is to check and make sure the domain name of the sender really exists. (While this is easy to force, every little bit helps.) Since all .COM and .NET domain names now exist, that anti-spam check is useless.

Hate to say it, but if the best you can do to combat spam is to check that the sender domain exists, then it's no wonder we get so much spam! Spammers thought of how to get round that one ages ago. Spammers can check that domains exist just as easily as anyone else. This so-called "important" anti-spam check was already useless - VeriSign hasn't changed this.

Any network administrator who says otherwise is just trying to bamboozle you with technobabble, in the hope that his employers and their shareholders won't notice that his wages are a complete waste of money.


This isn't about spam. It's bigger than that. It's about being bitten on the bum by a monopoly that we've allowed to grow without noticing it. In the past, we used to talk about Microsoft, AOL and Google monopolies - then VeriSign put it all sharply into perspective on Monday.

It makes a mockery of anti-squatting action too. If we knew VeriSign was going to do something like this, then we would all have been much more lenient on the cybersquatters.

And we also worry about future generations, who might not remember a time before VeriSign, when there used to be a thing called "freedom of speech".

I think the implications of VeriSign's action are huge, they go way beyond spam.

[silver]

I def think it's an abuse of their position,. it's like they've suddently got dibs on every single domain name that doesn't yet exist for their own marketing efforts,,. which can't be right,.

perhaps ppl will switch to the alternative DNS root tree..

Sil

PS - how does it work,. is it just a DNS trick - but verisign don't own the dns root servers do they?

[squidgy]

PS - how does it work,. is it just a DNS trick - but verisign don't own the dns root servers do they?

No, they don't. They're only responsible for the authoritative name servers for the .com and .net top level domains.

So, any hostnames made up of a subdomain of .net or .com that isn't owned by anyone will resolve to 64.94.110.11

For example ....

• verisign-are-chimps.com
• www.verisign-are-chimps.com
• ftp.verisign-are-chimps.com
• subsubsubdomain.subsubdomain.subdomain.verisign-are-chimps.com

... will all resolve to 64.94.110.11

There's a web server at 64.94.110.11. If the Host: field of your browser's HTTP request is anything other than sitefinder.verisign.com, then it returns an HTML redirect page, putting the contents of the Host: field in the query string of the address it redirects to. That's why your address bar changes.

Erm - have I explained that okay? Opinion in a mo.

[squidgy]

No, they don't. They're only responsible for the authoritative name servers for the .com and .net top level domains.

To add to that - VeriSign have no control over what happens on other top level domains, such as .biz .info .museum or any of the two-letter country-specific TLD's, such as .uk .nl .fr

My attitude has mellowed out a bit now.

Apparently Paxfire did the same thing on .biz earlier this year. But they had their knuckles rapped for it, so they pulled it.

But ICOM has been doing a technically similar thing with .museum for some time. A subdomain of museum that doesn't exist will resolve to IP address 195.7.77.20. There's a web server at this address, which helpfully offers you a list of .museum subdomains that do exist, and links to their home pages.

People say VeriSign have messed up spam filters, by wild-carding .com and .net. But if that was actually true, then ICOM would also be guilty of messing up spam filters when they wild-carded .museum. Oddly enough, no-one complained about that!

So in VeriSign's defence, they could say that's unfair.

But VeriSign and ICOM are different. If you put a hostname into the address bar of a web browser, it will try to turn it into an IP address. If it can't, then most browsers will stick .com after it, and try again. Internet Explorer, Netscape, AOL and Mozilla all do this, chances are Opera does too. This gives VeriSign a natural monopoly.

To that, VeriSign could say - so what? VeriSign don't make the browsers. It's not VeriSign's fault. Microsoft and AOL could have just as easily made their browsers to try .museum, or another TLD instead. Or just give up on wrong addresses. Or send the wrong address to their favourite search engine - Google, MSN Search, AOL Search, Altavista, or whoever pays them the most for the privilege. Many browsers already do this - but not until after trying the .com TLD.

My prediction - Paxfire set the precedent, so VeriSign is likely to be forced to pull out too. But they'll squeal about ICOM .museum. I think it would be a shame if ICOM are forced to pull out. I think ICOM's list of .museum links is genuinely useful - it's not like VeriSign's blatent advertising at all. (But then again, that's what we said about Google when we were comparing it with Altavista a few years ago, and look how powerful Google are now - or were ...)

I'm all in favour of alternatives to the ICANN root servers, and I think you'll see more alternative roots being set up in the next few months. But I doubt they'll make a big dent in ICANN's market share for several years yet.

[Ian]

ISC have released patches for its BIND DNS server (used by a mere 80% of DNS servers on the net) that work around this "feature"
http://yro.slashdot.org/yro/03/09/17...tid=187&tid=95

The problem with the mail server is it gives the wrong error back when you attempt to send email through it, meaning that the mail will just fail, so if the primary mx record mailserver domain disappears the mail will not get sent to the secondary mx mailserver. This is bad and defeats the object of having multiple mx records.

(ok, its still not *that* bad, just a *little* bad)

[silver]

Thanks for the explanation squidgy

I still don't like it tho

I guess adding a routing path to 64.94.110.11 - and making it null (somehow?) would remove the interferance ,. not sure how to do it - but it should be possible..

Sil

[squidgy]

I guess adding a routing path to 64.94.110.11 - and making it null (somehow?) would remove the interferance ,. not sure how to do it - but it should be possible..

Pleased my explanation helped. Another thing you could do is set the DNS for your local network, so that hosts which the .com authoritative servers resolve to 64.94.110.11 are ignored by your own DNS.

There's a difference between not being able to convert a hostname into an IP addresses, and not being able to make a TCP connection with whatever port number (usually 80 for the web) of an IP address that's already known. Internet Explorer gives you the same "This page cannot be displayed" error message either way. But other client software tells them apart. For example, SmartFTP says "Host not found" or "Software caused connection abort" And Mozilla says "Please check the name and try again" or "The operation timed out"

Obvious flaw - what happens when VeriSign change the IP address? There's probably a way of dealing with that, I guess this BIND patch would block non-existent .com domains, no matter what IP address VeriSign try and point them at.

The problem with the mail server is it gives the wrong error back when you attempt to send email through it, meaning that the mail will just fail, so if the primary mx record mailserver domain disappears the mail will not get sent to the secondary mx mailserver.

Sorry - don't quite understand. I know how to do MX resolution, but that's where you've lost me. When you say "mail server", do you mean the SMTP MX exchanger that receives all the mail for a particular domain? Or do you mean the SMTP relay, that receives all the outgoing mail from one particular network, and forwards it on to the recipient email address exchangers?

Thanks.

About my port scan results - I can see why port 80 is open, that's obviously the web search interface. But I have no idea what VeriSign gains from having port 25 open. Why are they hosting what looks like an SMTP server? And would it simplify the mail problems people are talking about if they didn't host an SMTP server? Thanks.

[squidgy]

I'm guessing here now, but I think the SMTP server is something to do with rejecting mail.

Correct me if I'm wrong, but, when a domain doesn't have an MX record, then mail relays will just look for an SMTP server on the A record IP address instead. For non-existent .com domains, this will be 64.94.110.11.

If there wasn't an SMTP server hosted on this address, then relay programs might assume that there's supposed to be a mail exchanger there, but perhaps it's switched off or something, and that someone might turn it on again a bit later. So it waits a bit, and tries again later a few times before it gives up. This would mean that anyone who tries sending email to .com domains that don't really exist, might not know about it for a few hours. Or even days.

However, the SMTP server helpfully rejects absolutely all mail that you try to upload, with a "550 user domain does not exist" message. So if you send mail to a .com domain that doesn't exist, you should know about it straight away.

[silver]

well - it's not that diff to stop the ip being addressed (could also do it by adding an entry into the hosts file I expect)

on win2k (don't know how to make it a static route tho)

route add 64.94.110.11 MASK 255.255.255.255 192.168.0.0 METRIC 1

I think an entry like

64.94.110.11 0.0.0.0

in the hosts file would prolly do it also?

Sil

[Onslo]

route add 64.94.110.11 mask 255.255. 255.255 192.168.0.0 -p

should set it up as a static/persistent route

You can check whether or not it's taken by checking the registry afterwards. Navigate to :

My Computer/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/PersistentRoutes

You should also be able to see it listed in the routing table at the bottom of ROUTE PRINT (persistent routes)

If you have Win2k/2k3 Server then you should really either use the "Routing and Remote Access" MMC snap-in or use the netsh command line shell.

'Slo

[NA-RYAN]

http://www.petitiononline.com/icanndns/petition.html

Petition against it.
Dunno what good it will do, but there I am at #7701

[squidgy]

Pleased by the implication that 7700 peeps have registered already. My own opinion ...

We internet users, who either own domain names or have an interest in the domain name system, wish to object to the Verisign Sitefinder system. We believe that the system:

1. breaks technical standards, by rewriting the expected error codes to instead point to Verisign's pay-per-click web directory, and threatens the security and stability of the Internet;

Breaks standards - okay maybe, but then again, so do firewalls. I don't believe it threatens security or stability of anything.

2. breaks technical standards affecting email services, and other internet systems;

ditto

3. is anti-competitive, providing Verisign with 20 million eyeballs per day for "free", while not paying for the domains they are resolving. All other market participants pay at least $6 per domain per year (wholesale);

Completely agree with that one, it takes the mick out of anyone who has bought or traded in domain names over the past few years.

4. violates trademark rights of domain holders, by typosquatting on their .com and .net domains; and

Arguable - but then again, so is the whole cybersquatting thing. However - if Joe Public isn't allowed to cybersquat, then that's a double standard.

5. violates the authoritative nature of DNS, turning it instead into a "best guess" system filled with uncertainty, thereby destroying the coherence of the DNS for Verisign's own short-term profit.

Eh? Not sure that there was ever an authoritative nature of the DNS system in the first place. Sure I know of the hierarchy, using root servers to find TLD authoritative servers, which in turn are used to find sub-domain authoritative servers, which in turn are used to find IP addy's of individual hostnames, or MX's, or whatever else you want from that domain. But people have been talking about the problems of getting too dependent on ICANN DNS for ages. Far worse things can happen than this.

Still, best of luck to them.

[silver]

from compwire..

VeriSign Inc, which shocked many in the internet community with the launch of a domain name redirection service last week, has said it will not deactivate the service, despite pleas from ICANN and almost universal opposition.

In a letter sent to ICANN, the body with which VeriSign has its contracts to run the .com and .net internet domains, Russell Lewis, general manager of VeriSign Naming and Directory Services said turning off Site Finder would be "premature".

"I would respectfully suggest that it would be premature to decide on any course of action until we first have had an opportunity to collect and review the available data," he wrote in a letter published yesterday.

Site Finder leverages (or abuses, depending on who you talk to) VeriSign's role as manager of the .com and .net top-level domains (TLDs). On the internet, every attempt to lookup a .com or .net domain ultimately takes its lead from VeriSign's servers.

Before last Monday, when a web user misspelled a .com or .net web address, they got an error message. Now VeriSign sends them to a web page it hosts that offers suggestions for correct spellings, a search box, and a directory.

VeriSign says it launched the service to make surfing the web easier for users. It gets about 20 million incorrectly spelled lookups every day. Some say the service could gross approximately $150m revenue for VeriSign per year.

Critics, which are legion, say Site Finder breaks applications, is monopolistic, raises huge privacy concerns, has security holes that could allow attacks, and may be a breach of VeriSign's contract with ICANN.

Two companies, Go Daddy Software Inc and Popular Enterprises LLC, have already sued VeriSign for over $100m, alleging the service amounts to an unlawful monopoly, unfair competition, and other breaches of the law.

Go Daddy's counsel Christine Jones said: "VeriSign is using its monopoly position to unfairly control internet traffic for its own economic advantage". She added: "Apparently Federal lawsuits are the only language VeriSign understands."

Jones said that the service means users have less incentive to visit a non-VeriSign registrar to check the availability of a domain. VeriSign owns Network Solutions Inc, the largest registrar of .com and .net domains.

ICANN, which was informed of VeriSign's plans just one week before the service went live, on Friday requested that VeriSign suspend Site Finder until a proper review could be carried out.

Rejected, ICANN now has its legal and technical people reviewing the service, according to a spokesperson.

VeriSign has set up an "independent technical review panel", which will "consist of leading experts in the field" to assess "any operational impact of our wildcard implementation", VeriSign's Lewis wrote.

VeriSign spokesperson Tom Galvin said that members of this panel are still being finalized, and names would be revealed this week. A timetable of roughly "a few to several weeks" is expected to complete the work, he said.

A spokesperson for ICANN said that to her knowledge no ICANN staff members or directors of the board had been approached to join the panel.

Galvin added that the company is working with the internet community, in the form of enterprises and technical bodies, to address the technical issues that have arisen (which are numerous, see separate article).

While VeriSign acknowledges there are practical technical issues, it believes its implementation is technically (from a standards point of view) and legally sound.

"We launched the service believing it is compliant with our contracts and consistent with RFCs," Galvin said. RFCs, or "requests for comment" are internet standards created by the Internet Engineering Task Force.

Paul Mockapetris, inventor of DNS, told ComputerWire two weeks ago that the service, then just in the trial stages, would probably not break DNS standards. He cautioned against other unforeseen problems, however.

The controversy surrounding Site Finder is likely to end up raising questions about VeriSign's suitability to run such a crucial portion of the internet' infrastructure. As a public company, it naturally answers first and foremost to its shareholders.

It could be argued, however, that the TLD space is now competitive, and that VeriSign is not the first company to launch this kind of "wildcard" system in a domain. The .tv Corp, for example, has had one for several years.

Even though alternatives such as .info and .biz have been available for a year or more, .com and .net are still far and away the most popular domains, especially in North America, where "dot-com" is still synonymous with the web for many.

Currently, VeriSign has the contract to operate .com until 2007, with the opportunity right to a four-year renewal after that. Its current deal with ICANN also means it has to re-compete for the .net contract in 2005.

and

VeriSign Inc's controversial new domain name system service, Site Finder, caused a number of technical problems, including one potentially dangerous security hole, when it abruptly went live last week, according to experts.

The company introduced a service that intercepts misspelled .com and .net domain name lookups and returns the address of a VeriSign web page where a search service is offered. The service could be a big money-spinner for VeriSign.

But critics claim the service introduces technical problems, serious privacy concerns, and security problems into the namespaces. They say that VeriSign should have, at the very least, consulted with the internet community before launching the service.

After undertaking a weeklong study, ICANN's security and stability advisory committee concluded yesterday that "VeriSign's change appears to have considerably weakened the stability of the Internet".

The committee added VeriSign has "introduced ambiguous and inaccurate responses in the DNS, and has caused an escalating chain reaction of measures and countermeasures that contribute to further instability".

Lance Cottrell, president of Anonymizer Inc, a web surfing privacy service, said that there was a so-called "cross site scripting" vulnerability in Site Finder, that could have allowed attackers to execute malicious code on a victim's computer.

Cottrell said that a hacker could have sent a victim a link to a non-existent domain with malicious script in it, and that the script would have executed. The code would appear to be owned by VeriSign, which is known as a trusted security service provider.

VeriSign spokesperson Tom Galvin said that this issue had been "identified late last week" and that "a fix was applied Friday". That is the only security issue, in the narrow sense of the word, to currently come to light.

But there are a number of privacy problems created by the service that many companies are regarding as potential security problems in the broader sense, according to experts.

Paul Vixie of the Internet Software Consortium, which maintains the popular BIND (Berkeley Internet Name Domain) DNS software, said his phone started ringing in the middle of the night after Site Finder was announced.

"I've never seen anything like it," he said. "My customers are very concerned about privacy... they want to make sure they don't accidentally form a transaction with or a session with VeriSign's servers."

Both Cottrell and Vixie said that because VeriSign is redirecting error traffic, using a feature of the DNS called "wildcards" it will also be intercepting email sent to misspelled or non-existent .com and .net domains.

Before Site Finder went live, if an email server tried to send a mail to a misspelled domain, it would get a "domain not found" type of message. Now, it will find Site Finder's servers, and instead return a "user not found" message.

According to Cottrell and Vixie, in these circumstances the full email, including the body text, is sent to VeriSign's servers. VeriSign is believed to have configured its servers to bounce these mails back to the sending server.

According to the Internet Architecture Board, which issued a scathing review of Site Finder last week, these "bounce servers" could create a single bottleneck for badly addressed email, reducing overall internet email performance.

"If the bounce server is buggy (which happened to be the case with this rollout), mail may not bounce at all," the IAB wrote, "it may be reported to the user as having been delivered correctly while actually vanishing without a trace".

The fact that email is sent to somebody other than the intended recipient is causing "extreme anxiety" among many BIND users, Vixie said.

Given that VeriSign operates under the authority of the US government, via the quasi-autonomous Internet Corp for Assigned Names and Numbers, this may be of particular concern to non-US .com and .net users, of which there are many.

VeriSign's privacy policy is, however, rather straightforward. It reads in part: "We do not collect any personal information from visitors to our Site Finder." Information is only collected in the aggregate, it reads.

Common to many privacy policies, it adds: "We may monitor statistics such as how many people visit our Site Finder, the visitor's IP address, which pages a visitor views, from which domains our visitors come and which browsers and browser settings visitors use."

VeriSign's Galvin said that the company has received some complaints from enterprises, but he said that he believes "they were largely addressed last week". He could not say if complaints were still coming in or not.

Galvin said the company is also working with certain spam filtering software companies to address a problem caused by the launch of Site Finder.

Some spam filters use domain name lookups to figure out if email is coming from a legitimate address. If it is coming from a non-existent domain, there is an increased chance that it is spam.

Some say that even if these concerns are being addressed, they should have been addressed in consultation with those effected before VeriSign went live with the service in the first place.

The IAB said, in the only piece of bold text in its Site Finder commentary: "If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone."

"We launched the service believing it is compliant with our contracts and consistent with RFCs," Galvin said. RFCs, or "requests for comment" are internet standards created by the Internet Engineering Task Force, of which the IAB is a part.

The IAB, which highlighted several other technical problems, recommended VeriSign turn off SiteMinder "at the earliest opportunity" while these issues are addressed and users are consulted. This view was later echoed by ICANN.

VeriSign, however, yesterday declined to do so (see separate story), saying it "would respectfully suggest that it would be premature to decide on any course of action until we first have had an opportunity to collect and review the available data".

Given that the Site Finder service, which affects virtually every internet user and has already caused problems for many, was launched with no official advance notice and no user input, the word "premature" seems an inappropriate choice.

Sil

[squidgy]

Hmm, interesting developments.

I still don't see much ground for proving that VeriSign have done anything wrong, given that no-one minded when other TLD's did something similar.

I think the best chance we have against VeriSign is to invoke laws about monopoly and competition. Isn't this how ABC was broken from NBC back in the 1930's?

As for Site Finder being a big money spinner - are we sure that advertisers want to be associated with it? How much can VeriSign charge for it? Will people click through? Would you buy anything you saw advertised on site finder?

Online advertising has taken a nose-dive over the past year or two, so I don't see how it will be different for Site Finder. But Google has been an exception. Maybe VeriSign plans to copy what Google have done - but I think the Google advertising business is still safe for some time yet.

[silver]

seems some ISPs are putting on the bind patch to make verisigns thing not work

also some scripts / hosts file changes will block it..

see http://www.spywareinfo.net/sep24,2003#verisign

Sil