A couple of the domain promotions that were scheduled to come to an end at the end of March have been extended.

Here’s the details:

• .IN: the $1.99 promotion will continue, but effective April 1st, 2010, the promo price increases slightly to $2.99. The promo will be extended through June 30th, 2010.
• .ME: The promo will be extended through June 30th, 2010 under the same terms.

Already signed up? You’re all set

For Resellers who are already taking advantage of the promotions, there’s nothing you need to do. We’ll extend it for you automatically. Resellers not signed up can visit our domains promotions page and sign up for the individual promotions that are currently underway.

Effective today, we’ve lowered the price on some VeriSign-branded SSL certs sold through OpenSRS. OpenSRS resellers automatically get the benefit of these lower prices which went into effect today, March 11th, 2010.

Sell the most trusted brand online

VeriSign SecureSite, SecureSite with Extended Validation (EV) and SecureSite Pro SSL certificates were reduced in price anywhere from $10 to $90 depending on the specific certificate and term length.

The full OpenSRS SSL Certificate price chart has been updated to reflect the new costs.

Today we announced significant improvements to the speed and quality of domain searches conducted using OpenSRS. With these enhancements, your existing integrations will work faster, as will searches using the Reseller Web Interface. But what I’m really excited about is the continued improvements we have made to our domain search over the past two years, which now allows you to offer an advanced domain searching system that will increase sales of both domains and other web hosting services.

A little bit of background

The methodology I refer to as “domain search 1.0” is unfortunately employed by most web hosting companies today. It is an old, archaic way of thinking about domain search. Common symptoms include:

• Forcing potential customers to enter ‘www.yourname.com’ search strings;
• Not allowing customers to register ccTLDs, or even gTLDs not named .com, .net or .org;
• The absence of suggestions for related search terms.

The most common objection I hear from web hosting companies is they don’t see any value in paying attention to domain name search, until I explain domain search 2.0.

Domain search 2.0

The domain search 2.0 approach treats domain names like the key component they are to the web hosting sales process. Virtually every web hosting company puts domain search front and centre on their website, but the technology used to power the search is often archaic. Domain search 2.0, on the other hand, treats the domain search box like a “magic box” – that is, an open, free-text box that will accept any input and spit out highly relevant domain names.

Our research shows this not only greatly enhances the end user experience, but can lead to a 10 to 15 percent lift in domain name sales if implemented properly. It also results in sales of more value-added services by attracting higher-margin customers.

How does it work?

The key to domain search 2.0 is our powerful NAME_SUGGEST call, which we’ve been iterating upon for more than two years. After our announcement today, it contains four key components:

• Domain name lookup: The “lookup” parameter will take any text and turn it into a domain name search, whether you enter “www.hockey.com”, “hockey league” or “hockey@league.com”.
• Domain name suggestions: The “suggestion” parameter will quickly return results of available names based on the original query using technology from DomainsBot, the industry leader in domain search technology. A new feature now allows you to also specify language if you choose to do so, enabling results to be returned in English, French, Spanish or Italian. Our research now shows that up to 15 percent of registrations using domain search 2.0 are from our domain name suggestions.
• Premium names: The “premium” parameter checks our premium names database of over one million names to see if any related names are for sale on the domain name aftermarket. As of today, suggested premium names are also displayed by DomainsBot, leading to a much better search experience.
• Personal names: A new “personal” parameter also allows you to now search for names associated with our personal names service as well.

We’ve also baked in a new “max_wait_time” parameter that lets you specify the number of seconds that the NAME_SUGGEST command can run, and return as many results as can be found in that time period. This will allow you to build real-time, AJAX-enabled domain searches if you choose to do so.

Putting it all together

Have you thought about your domain search lately? We now have the speed, tools and data to equip your business with a high-powered search that will lead to more sales. There’s more information on our website.

Looking for some more techie information about the new API?

Look no further! Read this post and see some code examples. And to dig even deeper, the Developers/API Forum is the place to be.

This is a quick example on how to use new features of the NAME_SUGGEST API lookup. As mentioned in my previous blog post, we added a new feature to the API that allows you to specify amount of time that you’re willing to wait for results. You would do it something like this:

{
protocol => 'XCP',
action => 'name_suggest',
object => 'domain',
attributes => {
searchstring => 'food toronto',
services => [ 'lookup', 'suggestion', 'premium',
'personal_names' ],
tlds => [ '.com', '.info', 'net', 'ca', 'co.in', '.co.uk', '.es' ],
max_wait_time => "1",
}
};

This search will check a limited number of TLDs (as specified in the call), but it will check regular lookups, name suggestions and premium names for each. Behind the scenes, all these checks will happen in parallel, after hitting the local cache and registry zone files that act as a secondary cache.

The parameter max_wait_time is the new feature. In this case, it means you’re willing to wait one second for response (as measured in our system; the total time for a response will include the roundtrip for the data to travel the Internet). We will collect all results that we can in that one second time period and return the results. The response will look something like this:

{
'protocol' => 'XCP',
'response_text' => 'Command completed successfully',
'is_search_completed' => '0',
'search_key' => 'Ln0ahqiOQ7H3Vab7sURVIronOks',
'action' => 'REPLY',
'response_code' => '200',
'attributes' => {
'lookup' => {
'count' => '10',
'response_text' => 'Command completed successfully.',
'response_code' => '200',
'is_success' => '1',
'items' => [
{
'domain' => 'foodtoronto.com',
'status' => 'available'
},
{
'domain' => 'foodtoronto.info',
'status' => 'available'
},
... (response cut here for clarity)

Now, many of the results will be determined and returned in one second, but it’s likely not all of them can be looked up in that time frame. However, even after we return result set, we continue collecting the rest of the results in the background.

If you’re building an AJAX interface, here is a neat trick you can use: Look at the parameter we returned called search_key, and you can reuse it:

{
protocol => 'XCP',
action => 'name_suggest',
object => 'domain',
attributes => {
'search_key' => 'Ln0ahqiOQ7H3Vab7sURVIronOks',
max_wait_time => "2",
}
};

In the call below you’re now using the search key parameter, and retrieving results that have already been collected for you. And you are also specifying that you’re willing to wait another two seconds. If you introduced some sleep() on your end before sending the second API call, you can drop this time too. At this point you will receive back something like:

{
'protocol' => 'XCP',
'request_response_time' => '0.002',
'response_text' => 'Command completed successfully',
'is_search_completed' => '1',
'action' => 'REPLY',
'response_code' => '200',
'attributes' => {
'lookup' => {
'count' => '10',
'response_text' => 'Command completed successfully.',
'response_code' => '200',
'is_success' => '1',
'items' => [
{
'domain' => 'foodtoronto.com',
'status' => 'available'
},
{
'domain' => 'foodtoronto.info',
'status' => 'available'
},
{
'domain' => 'foodtoronto.co.in',
'status' => 'available'
},
... (response cut here for clarity)

As you can see, another important addition is the new response parameter is_search_completed = 1. This value indicates that you have received the full result set, and that there is nothing outstanding. As long as there are still results to be obtained, is_search_completed will be 0, as in the first example…

Hope this helps. You can always visit the Developers/API section of the OpenSRS Forums to learn more about coding to the OpenSRS API.

I wanted to talk today about a few improvements we’ve done to our check-availability API functionality, also referred to as domain lookups.

In summary, we’ve made a number of improvements that will make check availability much faster, whether you’re using RWI or the NAME_SUGGEST API. If you’re integrating with our API now or in the future, NAME_SUGGEST is the call to use to take advantage of all the advanced features and speed improvements.

Warning: Geek Content Ahead

And, now, for geeks in the audience, here are a few more details…

Historically, lookups have been done sequentially in OpenSRS. Whether you were using the RWI or API, your choice was to request lookups one by one, or give us a number of TLDs, and we would check them one by one. In a Worst case scenario, you could wait as long as 60 seconds for lookup of all TLDs, name suggestions and premium names to be returned.

Well, that has all changed now. We’ve completely re-engineered the OpenSRS system for doing availability checks, and we’ve put a big honking internal lookup service in place that does number of pretty neat things:

1. All that work that used to happen in sequence, is now happening in parallel behind the scenes.
2. There is a new cache in place that stores previous lookups for a short period of time to enable very fast repeat searches.
3. We pre-load and regularly update zone files from the most popular of registries, and make this information available to the system as secondary cache.
4. Not only are all TLDs checked in parallel, but all related services are parallelized, including name suggestions and premium names lookups.

With the new system, we can handle over 8,000 concurrent requests, and have several hundred concurrent processes running at any given point. And this is just a beginning, as system is very scalable!

Working with our partners

To give you a sense of the painstaking engineering that went into this piece of the system, we worked hard with our name suggest partner on optimizing their API. By implementing our suggestions, they’ve cut average size of their API response from 177KB down to 0.6KB. Yes, there’s no typo there–that is less than 0.5% of initial size!

Additionally, we trimmed milliseconds wherever we could. The round-trip for name suggest call
has dropped from 1.1s to 0.5s, indicating that majority of this is processing time for name-suggestion engine spin.

What’s the payoff?

So what is the net result of all this? If you were to do lookup before for all gTLDs, ccTLDs, name suggestions and premium names, it would have taken about 60 seconds before. Today, with the new API system, you can expect back a complete set of results in around four or five seconds!

Basically, lookup nowadays will take as much time as slowest TLD. If you’re not selling all TLDs (and for reference .es and .in are some of the slowest we’ve seen), your response is likely to be even better that that. To get most often requested gTLDs, your experience will be around one or two seconds most of the time.

Max wait and search keys

And if you’re an API integrator, it gets better. When sending an API command, you can now specify the maximum amount of time you are willing to wait for results! We’ll time ourselves, and give you all the results we’ve been able to collect by that ‘deadline’. You can use this to make a really snappy interface at the expense of maybe not getting few results here and there.

I’ll follow up this post with another that will show you how to do it in the coming days.

As well, should you be building Ajax interface, you can make it both snappy and complete. Just send us two or three calls! With the first one give us one second, and get back the the fast gTLDs, and suggestions. Then redo the same query a few seconds later to pick up rest of the results. And maybe add one more call five seconds later, just in case…although the API will tell you if result set is complete, so you might not even need that last call.

In reality, there are number of strategies you can use with this feature, but I hope you see the potential. It’s powerful, but not complex, and it will enable you to build that snappy page, with a feel-good customer experience where things are just flying.

The .TEL domain extension is almost a year old and that means it’s time to think about renewals.

It was on March 24th, 2009, that the .TEL Generic Top-Level Domain (gTLD) launched into General Availability. That was the day that anyone could register their .TEL at the regular cost in a free-for-all landrush for available domains.

Now, as we are quickly approaching the first birthday of .TEL, it’s important that you remind those who bought a .TEL domain in those early days that it’s time to renew.

Telhosting Update Coming in March

To help you convince .TEL owners to hold on to those domains heading into year two, .TEL is rolling out an upgrade to the TelHosting platform. That’s the system that allows .TEL domain owners to edit their contact information, and it’s also responsible for the serving up of the actual .TEL webpage that each user gets with their .TEL domain name.

Telnic says that the new look was created based on feedback from the .TEL Community and features new templates, colours, social media integration and an embedded search:

“With the new design, you will be able to customize your .tel by choosing a colour scheme from a selection of templates and adding a link to your photo or logo. You can have a different graphic in every folder. For large .tel resources, the search function will also be useful, and you’ll be able to hide the “All .tels” search mode so that visitors won’t be allowed to go to other .tel resources from your page. Finally, the custom icons for popular online services will be added automatically when your .tel page is loaded.”

Selling .TEL

.TEL is different from regular domain names because it doesn’t require separate hosting, nor does the domain owner need to know how to create and manage a website to use it.

It’s a great solution for small businesses looking to take a first step in getting online, but it’s also a super way for companies and individuals that are already online to beef up their online presence and make it easier for customers to find them.

When you market .TEL, be sure to reach out to new customers, but don’t forget about your existing users who may already have a domain name–offer them a .TEL as an inexpensive complementary web service that will help them get found online and drive traffic to their regular website.

Effective Tuesday, February 9th, 2010, we’re implementing a new “soft-suspension” process for all users of OpenSRS Email Service. This new process is intended to mitigate the potential effects of spam sent by users of OpenSRS Email Service and to ensure good deliverability and reliable service for all users.

Full information about the change has been sent to all OpenSRS Email Service Resellers. Full details are available in the Resource Center – direct link.

Developers, crisis communicators, emergency planners, GIS specialists, technology workers, project managers and helpers are uniting around the world to use their skills and Internet savvy to help the Haitian earthquake victims.

People watched the news, donated money and then asked: can I help?

As a Crisis/Technical Incident communicator for Tucows/OpenSRS, I write all the incident reports, maintenance windows and system status updates for Resellers. Using the Internet tools to quickly get messages to customers is important for our business. Every day I work with some of the best techs in the world to make that happen. Tucows is very passionate using the Internet as an agent for positive change. I joined the CrisisCommons movement because this is a chance to use “agile actions” to help others. The CrisisCommons mission is to use this groundwork to help now and for all future emergencies. This is the power of the Internet flexing its community spirit and heart.

CrisisCamp – Haiti

CrisisCommons was started in 2009. It is a grassroots organization that facilitates partnerships and maintains a network of technology volunteers to respond to specific needs in times of crisis. From this, associated CrisisCamps are created to organize people who want to volunteer their skills to help NGOs, Emergency teams and Non-profit Aid organizations. When there’s a crisis or a need for CrisisCommons to respond, they come together for action.

It has been a heady week since our first CrisisCamp Haiti conference call last week. CrisisCamps sprung up in 6 major US cities last Saturday. Since then the momentum has grown and this weekend 12 camps are planned: from Boston to London, the UK to Bogota, Columbia to Washington DC to Seattle. There are three basic types of CrisisCamp activities: development help, social media (wiki, blog, cataloging, mapping) and general helpers. People are donating their time and helping to tackle projects ranging from OpenStreetMap to Mobile Development to a Haiti Hospital Capacity Finder.

I’m organizing Toronto’s CrisisCamp Haiti. Our first kick-off meeting is Sunday, January 24th, 2010. If you live in Toronto and want to help, please join us. Over at Butterscotch, our sister company, Michael E. Callaghan is contributing screencasts for CrisisCamp.

Our friends and hosting company partners joined together to create Hosting For Haiti. They are working with the American Red Cross to provide support, which may include mobilizing relief workers, sending relief supplies, and providing financial resources for recovery. You guys rock!

Do you want to get involved?

If you want to help, you can sign up for your local CrisisCamp (eventbrite sign-up). You can also follow Crisiscamp on Twitter to hear about all the global action happening.

• Crisis Commons site
• There’s a daily CrisisCommons conference call.
• IRC channel (Random Hacks of Kindness)
• Simple things that anyone can do. All you need is a computer, Internet access and some passion.

If there is no CrisisCamp event planned in your city or country but you want to get involved, you can contact CrisisCommons. I am also available to get you get rolling: Heather AT opensrs.com. If you know someone who would like to lend a hand, please spread the word.

Other news on CrisisCamp – Haiti:

Noel Dickover’s interview with the BBC (co-founder of CrisisCamp) [audio file]
Radar O’Reilly
IT World Canada
Article about Techs in the Toronto community

We regret to inform you that CNNIC has announced an indefinite suspension of all .CN registrations from overseas Registrars, including our registration provider Neustar.

As a result of this action by CNNIC, we have no choice but to suspend new .CN registrations through OpenSRS. We are in the process of disabling new registrations and we expect to have suspended registrations by end of day today, Tuesday, January 5th, 2009 (EST).

Please note that renewals and transfers will continue to be supported. Availability checks for .CN domains via the API and Reseller Web Interface will continue to work, however, orders for new .CN domains will fail.

CNNIC says the suspension will allow them to implement a better methodology to verify registrant information from overseas registrations. You will remember that in mid-December, CNNIC put into place new requirements for supporting documentation required to be submitted with new registrations.

There is no timetable for the resumption of new registrations. We’ll keep you posted as new information becomes available.

Last week, CNNIC, the Registry operator for the .CN domain extension, unexpectedly set out new rules surrounding the registration of .CN domains.

Since that announcement, we’ve been working with Neustar, our .CN registration partner, to determine the exact impact that these new policies will have on .CN registrations through OpenSRS.

The news is not especially positive.

These new policies, as set out by CNNIC, have a direct, negative impact on the viability of continuing to offer .CN domain registrations through OpenSRS. If you are selling .CN domains through OpenSRS, please stay tuned over the coming weeks as we address the business impact and make further determinations about how we plan to address continued support of .CN domains.

New Policy Details

Beginning December 21, 2009, all new .CN domain registrations will require the submission of additional paperwork to CNNIC in order to ensure that the registration is completed. The full text of the new requirements is available at: http://cnnic.cn/html/Dir/2009/12/12/5750.htm

In summary:

• Documentation for new registrations is now required to be submitted, by email or fax, directly to CNNIC. Do not forward documentation to Tucows/OpenSRS. Complete information about what is required along with documents for download can be found at http://opensrs.com/resources/domains/policies/#cn
• Failure to submit the required documentation within five (5) calendar days of the registration will result in the domain being deleted.
• New domain registrations will not appear in WHOIS or begin to resolve until the audit of the documentation has been completed by CNNIC. That process could take up to three (3) days from when the documents are received.
• Currently there is no process to track the progress of the audit process.
• Any .CN Registrations that fail due to incomplete documentation will be refunded monthly by OpenSRS.
• Renewals are NOT affected.

We recognize the significant impact this will have on .CN domain registrations. We continue to support .CN registrations through OpenSRS, with the understanding that the onus is on the Reseller to ensure that the proper documentation is submitted directly to CNNIC.