Skip to main content

Safe and Secure New gTLDs: ICANN Seeks Back-up Registry Operators | (Emergency Back-End Registry Operators or "EBEROs")

Updated 29 November 2011
23 November 2011

ICANN is issuing today a Request for Information (RFI) [PDF, 660 KB] to identify potential Emergency Back-End Registry Operators (EBERO).

One of ICANN's core missions is to preserve the operational security and stability of the Internet while also supporting open competition. With the upcoming launch of the New generic Top-Level Domain (New gTLD) program, the Internet will see a number of new gTLD registry operators. Although all applicants must meet technical, operational and financial requirements (see the gTLD Applicant Guidebook – http://www.icann.org/en/topics/new-gtlds/dag-en.htm) the community developed new gTLD program includes provision for a backup process. The EBERO is designed to be activated should a registry operator require assistance to sustain critical registry functions for a period of time or in the case of transition for one registry operator to another.

Candidates are expected to meet the requirements outlined in the RFI, which requires, for example, at least three years of experience in operating Domain Name services (DNS) and one year of experience operating Registration Data Directory Services (RDDS) and Extensible Provisioning Protocol (EPP) services. Besides the technical requirements, ICANN seeks candidates from geographically diverse regions in order to provide local service to registries in all regions and provide alternate sites in case of local disasters.

ICANN is looking forward to receiving comprehensive information from the potential candidates. Negotiations with certain respondents to the RFI that provide comprehensive information will be initiated for the purpose of creating process details and entering into an agreement to provide backend services. The deadline for responses is 5 December 2011 - 5:00PM Pacific Time. Please direct your information to ebero@icann.org. Responses after the deadline will not be considered.

RFI activities schedule at a glance:

Request for proposals issued by ICANN 14 September 2011
Respondents' Q&A – Teleconference On or about 16 November 2011
Questions and Answers: Emergency Back-end Registry Operators RFI (EBERO RFI) [PDF, 411 KB]
Written proposals due 30 November 2011 – 23:59 UTC
Extended to 5 December 2011 - 5:00PM Pacific Time

1. What is a registry?

A "Registry" is the authoritative, master database of all domain names registered in each Top-Level Domain. The registry operator keeps the master database and also generates the "zone file" which allows computers to route Internet traffic to and from top-level domains anywhere in the world.

2. What is an Emergency Operator?

Emergency Operator or Back-End Registry Operator is an organization that has partnered with ICANN to provide registry services in case another registry is unable to operate. The emergency operators will be selected by ICANN based on the criteria outlined in the RFI.

3. What happens when a gTLD registry operation fail either financially or due a technical emergency?

If an emergency occurs, and a Registry is unable to provide critical services, it will be the function of the Emergency Operator to ensure the continuity of the services. This provider emergency transition process is managed by ICANN and requires multiple providers to be available to take on the function in case one provider is not able to timely take the operation or if there is a conflict of interest.

4. What are the critical registry functions?

Functions that are critical to the operation of a gTLD registry (i.e., those provided by the EBERO) are:

  • Domain Names System (DNS) resolution;
  • Domain Name System Security Extensions (DNSSEC) properly signed zone (if DNSSEC is offered by the registry);
  • Shared Registration System (SRS), usually by means of the Extensible Provisioning Protocol (EPP);
  • Registration Data Directory Services (RDDS), e.g., WHOIS provided over both port 43 and through a web based service;
  • Registry Data Escrow.

5. What kind of information is ICANN requesting and who should respond?

Respondents should be parties interested in committing themselves as potential Emergency Back-End Registry Operators. The RFI covers numerous areas, but respondents should be prepared to discuss the following:

  • Capabilities and experience in the critical registry functions;
  • Registry Transition concepts, experience, SLAs, and use cases;
  • Pricing models for providing critical registry functions;
  • Profile of the respondents organization, leadership and resources.

Background

In April 2009, ICANN published the ICANN gTLD Registry Continuity Plan – http://www.icann.org/en/registries/continuity/. This document depicts a gTLD Registry Continuity Framework developed in collaboration with experienced gTLD, ccTLD registries and members of the technical community. The overall goals of ICANN's gTLD Registry Continuity Framework are:

  1. the protection of existing registrants; and
  2. to ensure confidence in the DNS.

The Registry Continuity framework recognized the need for a prescribed ability to continue services in the event of a Registry Operator failure. It introduced the concept of a Back-End Operator and the intrinsic complications in a single back-up operator supporting all existing capabilities of different registry models. In view of those complications, the concept of identifying base level "critical functions", required to maintain the minimum operating services of a Top Level Domain, was established and defined.

In May 2010 ICANN published a New Top-Level Domain Explanatory Memorandum "gTLD Registry Transition Processes Model" (RyTP) - http://www.icann.org/en/topics/new-gtlds/registry-transition-processes-clean-30may11-en.pdf [PDF, 747 KB]. This document further elaborates on the concept of critical functions required for maintaining Top-Level Domain services and discusses the types of transitions between one Registry Operator and another. The concept of the Emergency Back-End Registry Operator was also introduced to support the TLD critical functions of failing Registry Operators, when there is no immediate assigned successor Registry Operator.

Links to Relevant Information:


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."