No Such Weblog

According to Kevin Murphy (pointer from Bret Fausett), Verisign is internally testing a mechanism that would return resource records in response to queries for non-existing domain names; if the query comes from a web browser, the effect would be that users are redirected to a web page that presents existing sites to them.

Users and developers are deprived of the ability to choose themselves how to deal with such a situation -- by choosing web browsers that do smart things about non-existing domain names, by configuring their web browser to feed the bad address into their favorite search engine, or by just fixing their typo.

If the query does not come from a web browser, the behaviour described just means returning wrong error diagnostics, and creating another problem to route around.

What Verisign is testing here (and Neustar has "tested" in May, in a live registry) is a fundamental breach of the Internet's most fundamental design principle. And it certainly won't improve users' surfing experience.

If Verisign was actually striving to improve user experience, then it would not overload existing query types with new and bad semantics, but would suggest a new "fuzzy" DNS query type to which a name server can respond with records that point to possibly corrected query strings -- if the user's browser chooses to ask for them.

White papers on the mechanisms that Verisign apparently plans to implement for resolving unregistered domain names are available here.

The service seems to have gone live now, at least for .net. Concerns here, here, and here. Discussion at ICANNWatch.

Here's an illustration of what I mean when I complain about corrupting error diagnostics: During the past 20 minutes or so (it's now 1:38 a.m. GMT+0200), the address which is returned by the registry in response to queries for unregistered domain names was unreachable. The result? Instead of a quick message that I've mistyped the domain name, I get a timeout after waiting for quite some time. That's a highly misleading error diagnostic, and it's making the user experience much worse.

Which brings us to another problem with this: Verisign has been careful to put work-arounds in place that are supposed to mitigate the effects of the DNS change for individual protocols. These work-arounds depend on the availability of Verisign's infrastructure in order to work, though. Once this infrastructure is unreachable, users have no possibility to discern a non-existing domain name from an unreachable host.

Talking about user experience, I'm also sure that users of Asian localized software will very much appreciate getting English-language error messages from Verisign instead of localized and translated error messages from the software they are running.

SiteFinder is now also active in .com.

Meanwhile I haven't seen a single mailing list posting anywhere that would welcome this change -- but a lot of furor across the board, and some thought on how this can be stopped: People are modifying name servers that serve as resolvers to replace Verisign's sitefinder A records by the correct NXDOMAIN response.

Mike Palage (now an ICANN board member) on some mailing lists: Some Wild-Card Questions, about the specific impact of the Sitefinder service.

This AP story makes it sound as if sitefinder helps against porn typosquatting à la Zuccarini. Of course, it doesn't.

The At-Large Advisory Committee has released a Statement on Sitefinder. The statement explains why sitefinder is bad for individual Internet users, and urges ICANN to stop it.

Ross Rader on Jeff Neumann: On a day when half of the internet's smartest engineers are pointing out dozens of different applications and processes that have been broken by Verisign's actions, its hard to believe a lawyer that is arguing the opposite.

See also: Tim Ruiz' response.

BIND 9.2.2-p1 now supports tagging zones as "delegation-only". This can be used to filter out "wildcard" or "synthesized" data from NAT boxes or from authoritative name servers whose undelegated (in-zone) data is of no interest.

This effectively means that sitefinder-type records can now be blocked in ISPs' name servers.

Thinking about specific problems with sitefinder, here's a mail loss scenario: A site (a.net) is using a server in a different domain (b.net) as its backup MX. That server's domain expires and goes into the redemption grace period, or does not have any explicit name servers listed in the TLD zone for some other reason.

Image a.net's mail server is unreachable for a short period of time, because of maintenance. In the pre-Sitefinder world, e-mail for a.net would be queued up, since the backup MX can't be found. In the world according to Sitefinder, e-mail to a.net is directed to Verisign's "Snubby Mail Rejector Daemon", and (to the extent that Snubby works as intended) discarded.

Wietse Venema has just announced a new snapshot of his excellent Postfix mail transport agent. One of the two changes: Support to black-list domains by their mail servers or by their name servers. This can also be used to block mail from domains that resolve to Verisign's mail dump for non-existent domains.

Vote now.

Stratton Sclavos (the CEO that brought us Sitefinder) is one of the "candidates" in the Internet category.

James Grimmelmann, at LawMeme: Attention so far has been focusing on the ethics of the move (positive satanic), its effects on DNS and non-Web applications (Considered Harmful), and on possible technical responses .... On the legal side of the fence, though, we're not just talking about a can of worms. We're talking about an oil drum of Arcturan Flesh-Eating Tapeworms.

(Ross Rader reports that the first Arcturan Flesh-Eating Tapeworm has crawled out of the oil drum.)

Ross Rader points to a theory that Verisign's sitefinder may be experiencing something like a denial of service attack due to, among others, side effects from the Blaster worm's attempted attack on windowsupdate.com.

Florian Weimer rebuts that theory: The NS record continued to exist for windowsupdate.com, and that is enough to keep the wildcard from kicking in and synthesizing A records.

Via the GNSO council list comes a pointer to two presentations on Sitefinder that were given yesterday at the CENTR GA: CENTR's Kim Davies; Verisign's Scott Hollenbeck.

ICANN has published an advisory about sitefinder.

In a nutshell, ICANN is examining the situation (including the contractual questions that arise with respect to the registry agreement), and has requested input from the IAB and from the security and stability advisory committee. The latter committee is expected to deliver advice later today.

ICANN also has asked Verisign to voluntarily suspend the service until review is completed.

The Internet Architecture Board has released a commentary entitled Architectural Concerns on the use of DNS Wildcards.

The commentary gives both an explanation of some fundamental design issues that are created by the use of DNS wildcards, and an account of problems encountered in a recent experiment with wildcards.

Besides recommending strongly against the use of wildcards in TLDs (and most other situations), the IAB suggests a simple, but powerful guideline: 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 delegate within your zone.

The document concludes with the recommendation that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.

In a somewhat ironic move, Verisign has retired its "snubby mail rejector daemon" and has replaced it by postfix.

In related news, there's now an updated BIND patch for dealing with Sitefinder.

From an anonymous comment in response to the ALAC's statement on sitefinder:

In a recent Cnet article, Verisign is quoted as saying, "We're fully compliant with every RFC". ... If that's true, it just kills the argument against Verisign as it then becomes "geeks v. users" with Verisign on the side of the users.

That's a dangerous misconception, in several ways.

Reuters reports that Verisign will ask outside experts for advice about Sitefinder: They are going to create a committee of "Internet leaders" to advise it on technical matters. Recommendations on what to do, though, are apparently not welcome.

Of course, the necessary expert advice has been readily available for several days now. It's telling that Verisign convenes a committee (and wastes more time) instead of listening to what's out there.

I'd respectfully suggest that whoever is asked to join this group decline the invitation.

ICANN's Security and Stability Advisory Committee has issued some recommendations on sitefinder: Recognizing the concerns about the wildcard service, we call on VeriSign to voluntarily suspend the service and participate in the various review processes now underway. We call on ICANN to examine the procedures for changes in service, including provisions to protect users from abrupt changes in service.

Also, the committee is soliciting input on practical security and stability implications, to be sent to secsac-comments@icann.org.

In a letter to ICANN, the Public Interest Registry supports a suspension of VeriSign DNS wildcard service, and commits not to implement such a service for .org.

Some rather interesting remarks come close to the end of the letter: We are informed that other domain registries may be exploring services similar to the VeriSign Site Finder. ... If this is the case, our comments concerning Site Finder apply with equal force to those other services. ... Therefore, we urge ICANN to take whatever remedial action is needed to remove all "wildcard" DNS systems, including VeriSign's Site Finder, from the DNS. Such action, emphasizing the central responsibility of all service providers, would be an important step in preserving the openness and accessibility of the Internet.

It will be interesting to see what position the gTLD registry constituency's representatives on the GNSO Council will take tomorrow.

The GNSO Council's resolution on Sitefinder, as adopted today with the votes of all constituencies, except the registries (who abstained), and the IPC (which didn't attend) has just been posted by the GNSO Secretariat.

Commentary from Karl Auerbach is here.

ICANN has started to put incoming correspondence regarding sitefinder on its web site.

.au's Chris Disspain writes to Paul Twomey to echo many of the concerns with Sitefinder that have been raised by the SecSAC, and adds a specific focus on the process used (or, rather, not used) when introducing the service.

Register.com copies ICANN on a letter its law firm has sent to Verisign's chief litigation counsel, to protest Verisign's recently established SiteFinder service and to call upon VeriSign to immediately cease operation of the same. ... [T]he SiteFinder service consitutes an abuse of Verisign's power as the .com and .net registry, deceives the Internet community, confuses domain name registrants, and interferes with the business relation between Register.com and its registrants by means of deceptive acts and practices. The letter then focuses on the impact sitefinder has on registered domain names that have no name servers listed.

ICANN has posted an Information Page on Verisign's Wildcard Service Deployment on its web site.

It strikes me that this kind of content would greatly profit from being provided as an RSS feed.

Bret Fausett is moving to .org. Welcome to the wildcard-free part of the DNS!

There have been several recent comments that complain about the Terms of Service Verisign tries to impose with Sitefinder. James Grimmelmann has dissected their enforceability two weeks ago. Recommended reading for all those who wonder whether they may be bound by these terms.

ICANN's Security and Stability Advisory Committee will hold a special meeting on 7 October 2003 at The Center for Strategic and International Studies in Washington DC's K Street. The agenda: Gathering input regarding Verisign's introduction of Sitefinder. ICANN plans to webcast that meeting.

Alexander Svensson finds the location remarkable, and notes that this meeting will quite literally make the wildcard issue more accessible to the USG.

The registrars' constituency has sent a resolution to Paul Twomey. Key points:

• ICANN should immediately require that VeriSign suspends [Sitefinder] and returns a "NXDOMAIN" response for zone file entries that do not exist;
• registry services should be compatible with the relevant agreements, and the security and stability of the DNS;
• gTLD registries should be required to follow a predetermined process when introducing new services in the future; that process should in particular investigate contractual questions, and security and stability implications.

Verisign has set up a Technical Review Panel that is chartered to look at implementation issues, to determine what enhancements could be made to improve the service, and to report the observed implementation issues to VeriSign along with any data supporting such issues. The committee is chaired by GNSO chair and SecSAC member Bruce Tonkin (Melbourne IT; conflict of interest statement; Melbourne IT letter to ICANN).

This committee looks like another attempt by Verisign to distract people into discussions about implementation details of the Sitefinder service (there's certainly room for improvement), in order to avoid the architectural concerns (which can only be addressed by dropping the service entirely).

See also: Ross Rader's take of the issue.

Andersenccenture puts Verisign in charge of electronic voting, and everyone around has the same association.

Wendy Seltzer: What's next, ballot-box wildcards?
Ross Rader: The great thing is that if voters type in the wrong vote, Verisign has the technology to point them in the right direction.
Martin Schwimmer: VeriSign announces VoteFinder Service.

Seems like I missed most of the final showdown of Episode I of the wildcard wars today. Here's the wrap-up.

In a letter to Verisign (advisory here), ICANN has demanded that Verisign shut down sitefinder by 6 pm PDT tomorrow, until open technical issues are resolved. At the same time, the GNSO is requested to work out a procedure for the introduction of new registry-level services by 15 January 2004.

See also: Commentary by Chris Ambler; discussion at ICANNwatch; discussion at Slashdot; reactions at CircleID.

In response, Verisign has announced that it will temporarily shut down sitefinder (it seems like this step has not yet been implemented, though). It's remarkable that Verisign spokesman Tom Galvin is now quoted characterizing Sitefinder as a non-registry service.

See also: More ICANNwatch discussion; Chris Ambler; Verisign press release.

Two interesting postings from the nanog list: Owen DeLong writes to the Washington Post's ombudsman and offers detailed comments on David McGuire's October 3 article; William A. Simpson writes to the New York Times and explains what's not in Elizabeth Olson's report.

This shows that, while Sitefinder is bad for average users, a lot of spin is currently emanating from Verisign, and needs to be busted.

ICANN's Security and Stability Advisory Committee page now has detailed information about the agenda of tomorrow's meeting. The meeting will be webcast; remote participants will need to have realplayer installed.

The latest exchange of letters between ICANN and Verisign is now available from ICANN's web site.

In response to ICANN's pressure last Friday, Verisign's Rusty Lewis accuses ICANN of a violation of the Registry Agreement as well as an anti-competitive interference with VeriSign's existing contractual and other advantageous business relationships. Threatens Lewis: VeriSign fully intends to hold ICANN accountable for the damages caused by its improper actions.

In a second letter, also dated 3 October, Lewis complains about lacking neutrality in ICANN's Security and Stability Advisory Committee, and about lack of opportunity to debunk some of the misconceptions currently being forwarded.

In a letter from Monday, Twomey responds. He rejects Verisign's concerns about the SecSAC and tomorrow's agenda, and suggests that SecSAC should hold a second meeting two weeks later or at such a time as VeriSign is ready to state its full technical position. Verisign is also formally requested to release its testing data from before, during and after the Service Change and to do so well in advance of the Second Meeting.

Verisign's latest spin goes like this:

ICANN caved under the pressure from some in the Internet community for whom this is a technology-religion issue about whether the Internet should be used for these purposes.

For this vocal minority, resentment lingers at the very fact that the Internet is used for commercial purpose, which ignores the fact that it's a critical part of our economy.

That's, of course, outrageous nonsense. What Verisign attempts to do is to throw out services that are being provided at the network's edges by abusing its government-granted stewardship role for .com and .net.

The objection here is not about commercial use of the Internet: It's about keeping the net's architecture open for commerce. It's about keeping an architecture which enables different players to compete by providing innovative and better services to customers.

Verisign's sitefinder, however, is no such service: The only "innovation" here is to change the net's architecture in a way which makes it impossible for other players to compete with Verisign.

Time for a re-bid?

The SecSAC meeting on Sitefinder in Washington DC is about to begin.

General Meeting Information · Agenda · Webcast

Comments can be sent to secsac-comment@icann.org.

First, links into my notes: Hollenbeck, Schairer, Vixie, Smith, Bellovin, Klensin (+ discussion), final discussion. I suppose that electronic versions of the presentations will show up somewhere on the SecSAC site.

Nothing unexpected happened: Verisign tried to be collaborative with respect to fixing individual technical issues (suggesting, e.g., to introduce a wildcard MX record instead of running a bounce server), but did not seem willing to compromise on the design side of things.

The best presentations were clearly given by Bellovin and Klensin; however, they were hard to transcribe given the high information-per-time density. Both made the importance of the Internet's end-to-end design for innovation -- and the importance of a properly functioning DNS for that design -- abundantly clear. The message from their talks is that sitefinder is not just a bad idea because of individual side-effects, but because of the service's fundamental design.

Finally, the question asked by (I believe) K Claffy from CAIDA in the end of the meeting is indeed interesting: What kind of testing did Verisign actually perform before rolling out Sitefinder? What kinds of hard facts were generated during that testing process? (I'd add one more, though: How could the "snubby mail rejector daemon" survive any kind of rigorous testing?)

Verisign Statistics:

-- 84 percent of Internet users who have tried Site Finder said that they preferred the service to receiving an error message.
-- 65 percent of Internet users reported that they found the service easy to use while 61 percent said that Site Finder enabled them to find what they were looking for.
-- 53 percent of Internet users said that Site Finder improved the Internet (an additional 35 percent of users thought it improved the Internet somewhat).

How many of those surveyed speak a language other than English as their native language? Remember, sitefinder is exclusively available in English.

PS: That particular press release quotes a user talking about 404 responses. 404 is an error generated by a server when you reach it. It doesn't have terribly much to do with Sitefinder.

There's another Security and Stability Advisory Committee meeting in Washington DC on Wednesday, to focus on VeriSign's planning, data collection and analysis of its experience.

The following material from the October 7 meeting is available: Morning Session Video; Afternoon Session Video; Real-time captioning; Agenda and Presentations.

Later: The meeting on Wednesday will be webcast.

The delegation-only patches to BIND that have been deployed in response to Verisign's sitefinder service happen to break e-mail to first@last.name, since the TLD server directly returns MX records. No wildcards are involved here.

Global Name Registry to ICANN: Global Name Registry is disappointed to see .name customers being caught up in the crossfire between other parties on the Internet and what has perhaps been an emotional rollout of a technical countermeasure to the .com and .net zone change.

The SECSAC's second meeting on sitefinder is going to begin at 1 pm EST. The webcast URL has now been posted to ICANN's web site.

Presentations already available from the agenda page: VeriSign, Edelman.

PS: I don't promise to take extensive notes this time.

At the DC workshop, the Q&A is going on as I type this. Verisign is being grilled about their "user survey." Verisign tries to spin Sitefinder as a pro-user service that was accepted well. Secsac members are raising doubts about what kinds of questions were asked, and are trying to drill down to what was actually asked. Verisign refuses to release the questions asked, though.

I've submitted two questions to the SECSAC's comment address. Both were read; thanks!

• How many of the respondents to the surveys quoted (which included users from Germany and China) do not speak English?
  Answer: "don't know." I'm actually starting to wonder what language was used for the survey questions in these countries.
• Verisign says it does not use the wildcard to collect personal data. What about the third-party (Overture) web bug placed on the Sitefinder site?
  Answer: Web bug exists. Planning to do minimum information only. (?) Opt-out? No. Consistent with privacy practices. Crocker explicitly speechless.

Some interesting discussion between Crocker and Verisign people on whether this is a registry service change. Crocker insists that core of registry function was changed. Gomes emphasizes RFC compliance. Counsel to Verisign steps in and notes that some terminology ("registry service") is loaded with legal meaning.

Several people ask why a user survey is thought to be relevant for security and stability and presented at this meeting. No conclusive answer.

Question about service survey conducted -- can Verisign make data available? Answer: Results are in the slides; data are proprietary.

Closing question from Rick Wesson: Further undisclosed testing with non-delegation records? Long silence. "If move forward, testing needed, to provide secure and stable service." Crocker: Good. Rick: No. Crocker: Good that we understand situation.

Today's presentations and statements (as far as they related to the technical side of sitefinder) fit well with what became evident at the last meeting: Verisign is trying to play nice with respect to collateral damage, they are helping people to fix what can be fixed by changing client software, but they are not moving on the wildcard itself.

Two problems with that: 1. They are causing cost to others on the net by making changes at the center that have to be worked around at the edges. The side effects of the root-delegation-only BIND patch on .name are just one example. 2. Fixing the collateral damage does not give users the choices they have now (but haven't with a wildcard).

At the October 15 SECSAC meeting, VeriSign had presented results from a survey of end users in the US, the UK, Germany, and China. According to the VeriSign slides, 61% of users surveyed in Germany preferred SiteFinder somewhat or strongly; 76% in China, 81% in the UK, and 84% in the US.

Back on October 15, I asked how many of the respondents to the surveys quoted (which included users from Germany and China) do not speak English, and started wondering what language was used for the survey questions.

I'm now hearing that the survey was conducted in English.

Since last week-end, sitefinder.verisign.com (the search engine to which the wildcard redirected) no longer resolves. The final nail in the coffin, or the first step towards re-branding and re-launching?

Ira Rothken on Politech: We decided to add ICANN and the United States Department of Commerce to our Federal Case in Northern California (Syncalot v. Verisign) involving the legality of Verisign's SiteFinder service. We added the above additional parties in an effort to have a more complete record and a full and fair adjudication of the issues. We are seeking to enjoin the SiteFinder service and declare it illegal. Here is a link to the First Amended Complaint which alleges, amongst other things, that Verisign breached its agreements and violated the law when it attempted to use control of the domain name root server to "break the Internet" and monetize domain name properties it did not own.

Later: Bret Fausett has read the complaint and suggests that the lawyers in question haven't done their homework.

Washington Post, VeriSign Reconsiders Search Service (TechNews.com): Stratton Sclavos, chief executive of VeriSign Inc., told investors in a conference call last month that the company might relaunch its "Site Finder" service as early as April.

(Link credit: IP.)

Washington Post: Suit Challenges Powers of Key Internet Authority (TechNews.com)

VeriSign has sued ICANN over SiteFinder, and -- apparently -- also over delays in IDNs and WLS. Essentially, it seems like the new registry services issue has just been moved from the GNSO to the court system.

Discussion at ICANNwatch.

Verisign's response to SSAC is a messy combination of very few good arguments (just why was the limited IDN wildcard so much better than sitefinder, again?), silly distractions, and simple misstatements. The purpose of this entry is to address some plainly misleading parts of the document.

On page 6, for instance, the report takes up SSAC's footnoting of my presentation in Carthage, and claims that the comments summarized there were somehow triggered by ALAC's statement on sitefinder. We're flattered by the impact that is attributed to ALAC's statement -- but I didn't summarize the few comments ALAC received on the topic, but the 200+ ones sent to ICANN's overall wildcard-comments address.

Verisign (on page 9) continues to claim high user acceptance based on some polling, and alleges that it made sufficient information about the surveys available. That's a bad joke: I still haven't even seen a public, on-the-record answer to the question in what languages the survey was conducted (the answer is: English) -- an important factor when VeriSign claims user satisfaction with an English-language service forced on users in countries such as Germany or China. Also, the questions asked in the surveys still haven't been published, to the best of my knowledge. As far as I'm concerned, Verisign is still in the how to lie with statistics department here.

On page 5, VeriSign complains that SSAC didn't follow up on offers by VeriSign to make relevant data available. Elsewhere, there are complaints about lack of transparency. So, why doesn't Verisign just publish these data?

There's more to be said about other parts of the report -- claiming that Sitefinder fixes 404 errors generated by web servers (after successful resolution of a domain name), talking about format and protocol compliance when operational procedures are at issue, going to great lengths of discussing the confines of SSAC's mission while avoiding to reply on substance, conflating changes close to the network's center (sitefinder) with changes close to the edges (firewalls), claiming that hacks deployed at ISP name servers equate end user choice.