Deciding how and when to launch a new generic Top-Level Domain (gTLD) or brand Top-Level Domain (TLD) is not unlike deciding to conduct a worldwide tour to key destinations to help boost your marketing efforts. You want to decide what results you expect, who you’ll target and what messages you want to send them, as well as study your options and understand them clearly. Only after you’ve done that do you book your travel plans.

Think of the back-end registry system as the mode of travel. That mode is important, but you have plenty of options. First, though, you need to know where you want to go, metaphorically speaking, before you schedule flights, trains or car rentals. My Architelos partners John Matson and Alexa Raad have described in other CircleID posts (here, here, here and here) the importance of identifying a unique market value to your registry offering.

The back-end registry system is sometimes referred to as the back-end registry or simply the registry. It’s a little confusing as a new TLD is sometimes referred to as the TLD registry. Launching a new TLD requires that the new TLD owner become a registry. Back-end registry systems are sometimes called registries when what they really are is the core technical infrastructure you’ll need to conduct your business.

What they don’t supply is the front-office systems you’ll need—marketing, contract management and compliance work flows, registrar management, sales and marketing portals, financial data and forecasting and business intelligence reporting, etc.

But the back-end registry system interacts and services your sales channel, the registrar(s), accepting registrations and related data from the point of sales in real-time. In turn, it provides the source for DNS (and DNSSEC), Whois and your Escrow system, and of course, your sales transactions and revenue flow through the registry system. Sound important? It is, but not just in the standard bullet-proof operational sense.

There are many operational considerations for a registry. The ICANN Application Guidebook helpfully does a respectable job of listing the critical registry functions for the generic registry. However, you need to consider a lot more than just the basics. You have a sales channel to impress, and with many new TLD registries coming onto the marketplace, there is going to be a lot of competition for registrar shelf space.

Your sales channel also has a real cost to selling your registry product. A registry that works cost effectively with registrars makes it easier for them to carry your registry product.

Speaking a Common Language

It’s safe to say most everyone, particularly in this case registrars, hate doing repetitive, unnecessary work. Starting back in 2000, a group of volunteers worked to develop a common, reusable registrar/registry interface that helped limit the integration work between the two entities. Together we (I was part of this effort when I worked for a back-end registry provider) developed and implemented EPP (Extensible Provisioning Protocol) as the industry standard communication protocol between registries and registrars. This protocol contains a series of standard TLD registry functions and provides a framework for custom functions known as EPP extensions. It’s important to ensure any registry back-end provider you select is up to date with the latest EPP versions, including EPP standards related to DNSSEC, which is required, and Redemption Grace Period, which is optional but typical in industry.

Working With Registrars

There are a lot of sometimes obvious, and often quirky, reasons why a registrar will like integrating with a given back-end registry system. Before signing on with a registry system, you should ask your prospective registrars who they like integrating with and why. The reasons can be varied, but common ones include: excellent test environments; extensive registry toolkits for their developers; good registry implementation support staff; clear operational FAQs for registrars; excellent reports; and an intuitive, well-thought out web portal access to interact with the registry. Whereas most registry transactions happen between servers and clients (machine to machine), troubleshooting and select activities often require the registrar staff hands-on access to the registry. When that registrar staff has to access many registries, learning a new registry web portal interface becomes a burden. Which is why the registry web portal should be self-directing and easy to learn.

Back to Bullet-Proof

ICANN has substantial requirements for service level agreements. I will be covering those in detail in a later CircleID post. But for now we need to consider the basic drivers behind availability.

The first is simple economics: If you are running a revenue earning registry, the longer your store (the registry) is open, the more sales can flow through it. This is particularly true if you have a market that spans multiple time zones.

The second is much more dire: Remember all DNS changes start at the registry. This means if a registrar or registry operator has a compelling reason to shut down a domain and its services, for any reason, the back-end registry system needs to be available to do so.

In understanding service availability, make sure you fully understand how and where your registry services provider operates their registry systems. Ask how maintenances work in detail and ask them to provide details on the maximum length of those maintenances in the last few years. Review their disaster recovery plans and ask to see third-party verification that their plans are adequate and have undergone appropriate test exercises.

Features for the Future

You should take careful stock of what your registry back-end provider stipulates in the package they offer you. Typically a package includes many industry standard features and sometimes a whole host of optional features that often are very desirable such as IDN support, deferred revenue functions, data warehousing, complex domain registration restrictions and registrant membership support functions. It’s a long list. However, many of these features may be designed for the most common use case and could need adjusting for your registry business cases to be implemented properly.

Ideally, you want to have your registry business case and effective requirements fully defined prior to signing a contract with your registry service provider. That said, your registry model will evolve with the market so make sure you understand your provider’s ability to make adaptive changes in development cycles that support your business. You want change request fulfillment commitments in your contract that include turnaround times based on classes of change complexity. For example, a request for a simple new report (required data is available) might have a committed turnaround of 30 days, whereas a complicated one may have 60-90 days. Bottom line is make sure you understand the ability and commitment of your provider to make changes if you truly need them.

In review:

• Make sure you have a strong, well-defined business case before choosing your back-end provider.

• Ease of technical/operational integration with your registrars/sales channels is important to help win shelf space.

• Extremely high availability for your core registry system is important to registrars and registry operators, and ultimately to your registrants

• Know your provider’s ability/willingness to make changes and ensure you have the required flexibility for your opportunity.