Skip to main content

ICANN gTLD Registry Failover Plan

Section 1.1.2 of the 2006-2007 ICANN Operating Plan states that ICANN will "Establish a comprehensive plan to be followed in the event of financial, technical, or business failure of a registry operator, including full compliance with data escrow requirements and recovery testing."

The Operating Plan also states that ICANN will "publish a plan supported by the infrastructure and data escrow procedures necessary to maintain registry operation." Based on community input received on the 1 June 2007 Registry Failure Report and Protections for Registrants Workshop in San Juan , Puerto Rico, ICANN has developed a draft gTLD Registry Failover Plan. ICANN intends to socialize the plan with members of the community between now and the Los Angeles meeting.

The plan is based on the assumption that ICANN has a role in the event of a registry failure. gTLD registries must have a contingency plan, including the designation of a backup registry operations provider if necessary, to maintain the critical functions of a registry for a period of time:

  • To provide recovery and escrow of domain name registration information and registrant account information, so that
  • A replacement operator or sponsor can be found and a transfer effected, or
  • Absent the designation of a replacement, provide a notice period to registrants that the registry is closing.

The gTLD Registry Failover Plan is part of a larger package that will be presented to the community, which will include a best practices document describing registry failover mechanisms and transition elements.

  1. Definitions

    The following definitions are used to describe the gTLD Registry Failover Plan.

    1.1 Initiating Event — The occurrence of an event with the potential to produce an undesired consequence. An initiating event may be any event that creates a potential or reasonable risk of a meaningful adverse effect on Security or Stability of the TLD or the Internet.

    1.2 Temporary Failure — A registry failure where there is certainty of data recovery or restoration of service in a reasonable period of time.

    1.3 Long-term Failure — A failure rendering a registry or a critical function of a registry inoperable for an unacceptable length of time.

    1.4 Critical functions — those functions that are critical to the operation of a gTLD registry. The registry failure report published on 1 June 2007 identified seven critical functions of a registry, although there may be others.

    1. Maintenance of nameservers and DNS for domains
    2. Shared Registration System
    3. WHOIS service
    4. Registrar Billing and Accounting Information
    5. Data Security and Data Escrow
    6. IDN Tables (if IDNs are offered by the registry)
    7. DNSSEC Keys


  2. Notification When an Initiating event occurs

    2.1 ICANN learns of an initiating event at a gTLD registry or sponsor.

    2.2 ICANN may receive information on an initiating event from a registry, registrar, or other member of the community.

    2.3 The initiating event creates a response time line from ICANN staff.

    1. Initiating event occurs at time X
    2. Notification is provided by Y
    3. Y is expected to provide ICANN with as much detail regarding the nature and impact of the event as is available (and practically possible to collect) within the time frame
    4. ICANN staff studies information provided during time frame, ICANN responds to the party who notified ICANN, and if appropriate, contacts the registry (if the registry did not already notify ICANN staff)
  3. ICANN Preliminary Examination

    3.1 ICANN staff conducts preliminary examination based on facts known of the event. The staff examination may be conducted between members of the ICANN Office of General Counsel, Registry Liaison staff or other staff as appropriate.

    3.2 A decision is made on whether to contact the registry, who to contact and how to contact them.

  4. Communication with gTLD registry or sponsor

    4.1 Following the ICANN preliminary examination and decision to contact the registry, ICANN will attempt to communicate with the designated gTLD registry contact (or sponsor or registry operations provider, depending on the terms of the registry agreement and preliminary examination). This contact should be someone with authorization to act on behalf of the registry.

    If the registry or sponsor can be reached, ICANN will attempt to determine the following:

    1. The type of initiating event
    2. The cause of the initiating event
    3. The severity of the event (temporary or long-term)
    4. Whether the registry can continue operations
    5. Question what, if any, services will be unavailable or operated at a reduced level of service
    6. Whether the registry has interim measures in place to protect registry services

    The determination on whether a registry can continue operations should be made in consultation with the registry. There may be circumstances when a registry can provide limited services (DNS, but not registration or change services) for a temporary period without the need to transition operations to a backup provider.

    4.2 If the registry or sponsor cannot be reached and a backup registry operations provider is available, ICANN should contact the backup registry operations provider or seek alternative confirmation of the event and contact the third party data escrow provider.

    1. Execute agreement (or initiate procedure) for release of data from escrow
    2. Obtain data from escrow and copy zone (if available) to maintain resolution of names

    4.3 If available, the gTLD registry or sponsor confirms contact and provides information on the initiating event as a non-event, temporary failure or long-term failure.

    4.4 If the registry's failover plan activates a backup registry operations provider, the backup provider must make contact with ICANN and confirm the level of service to be provided to registrants (full service or resolution-only service). ICANN will consult with the backup provider to ensure that names in statuses such Pending Delete or Redemption Grace Period are not inadvertently lost.

    4.6 The backup provider will ensure that critical functions of the registry are preserved.

  5. Internal Communications Plan

    5.1 Following contact with the gTLD registry or sponsor, or independent confirmation of the initiating event in the situation where the gTLD registry or sponsor cannot be contacted, ICANN may consult with experts based on the type of event and determination of the event as a technical failure, business failure or other failure. The type of failure will trigger a different level of response from ICANN.

    Following the decision to contact the registry, ICANN shall initiate its failure communications plan and assemble a crisis team. The team shall consist of:

    1. VP of Corporate Affairs
    2. Media adviser
    3. General Counsel staff
    4. SVP, Services
    5. Registry staff
    6. Registrar staff
    7. Chief Security Officer
    8. Chief Technical Officer
    9. Compliance Program Director
    10. If applicable, IDN Program Director
    11. Other staff, as necessary

    Each of these roles shall be clearly defined and preferably each role should have a designated back-up person. ICANN shall test its crisis management process.

    5.2 The team shall inform the CEO, COO and Board of the event, the type of failure and course of action.

    5.3 The VP of Corporate Affairs is ICANN's designated spokesperson in the event ICANN's crisis team is assembled. ICANN will inform the Internet community based on the specifics of the event, the need to know and what is disclosed should be limited based on the perceived impact on affected parties.

    5.4 ICANN shall endeavor to keep the community informed of the failure and the course of action.

    5.5 ICANN may consult with external experts on the determination of failure and the actions to be taken in response to the failure event.

    5.6 In a temporary failure (a registry failure where there is certainty of recovery in a reasonable period of time), ICANN will communicate with the registry or sponsor and provide technical assistance where appropriate or requested by the registry or sponsor. Based on the severity of the event, ICANN's communications plan may be invoked to ensure that the community is informed.

    5.7 In a long-term failure, ICANN shall examine the cause of the failure and whether the failure occurred as a result of technical, business/financial or other reasons.

  6. Communication with registrars and registrants

    6.1 If necessary, Registrars shall be advised not to accept any new registrations in the TLD(s).

    6.2 Registrars should be advised to maintain a copy of names under management in the TLD (or TLDs if the operator maintains more than one) and ensure proper escrow of registrant data in accordance with ICANN's registrar data escrow specification.

    6.3 The gTLD registry (or the backup registry operations provider) shall inform registrars of the failure. If the registry is a sponsored TLD, the sponsor should inform the members of its sponsored community. If this is not possible, ICANN shall provide notice to the community and make best efforts to provide notice to registrars and registrants.

    6.4 ICANN will confirm with registrars on notice to the community and registrants.

  7. Decision on whether the registry or sponsor can continue operations

    7.1 Based on available information and guidance received, a decision is made on whether the registry or sponsor can continue operations. The decision should be made in consultation with the registry.

    7.2 If the registry or sponsor can continue operations, agreement is reached with the registry or sponsor on the timeline for return to normal operations and on the status of the TLD zone.

    7.3 ICANN may offer to provide or locate technical assistance to the registry or sponsor, if appropriate.

    7.4 ICANN and the registry or sponsor shall provide notice to the community of the timeline for return to normal operations.

    7.5 In the situation where the registry or sponsor cannot continue operations, the registry or sponsor will invoke its contingency plan to activate a mirror site or backup registry operations provider to ensure continuity of service for the TLD. ICANN may also offer temporary resolution-only service for the TLD if asked by the registry or sponsor.

    7.6 ICANN will inquire whether the registry or sponsor has identified a backup registry operations provider and whether the registry's failover plan has been invoked. ICANN will inform the ICANN Board and advisory groups, as appropriate.

    7.7 If the registry or sponsor has identified a backup registry operations provider, the registry or sponsor will follow its own registry failover plan to ensure continuity of service for the TLD.

    7.8 Once a backup registry operations provider is engaged by the registry or sponsor, the backup registry operations provider must meet ICANN requirements for operating a TLD. ICANN shall obtain assurances of continuity from the backup registry operations provider.

    7.9 If the registry or sponsor has not designated a backup registry operations provider, in an emergency, ICANN may provide temporary resolution-only services until the TLD can be transitioned to a successor.

  8. Voluntary Transition Process

    A voluntary transition of a TLD is necessary when an event occurs that renders a registry or sponsor unable to continue operation of the TLD. The registry or sponsor and ICANN shall cooperate with ICANN in efforts to promote and facilitate the Security and Stability of the Internet and the DNS

    8.1 ICANN and the registry or sponsor will consult on voluntary transition of the TLD. If the registry or sponsor has made a decision to voluntarily transition the TLD, ICANN and the registry or sponsor will agree to work cooperatively to facilitate and implement the transition of the registry for the TLD in a reasonable timeframe (30-90 days), with notice to the community.

    8.2 The registry or sponsor may locate a buyer for the TLD within the transition timeframe. The buyer must meet ICANN criteria to operate the TLD.

    8.3 If the buyer meets ICANN criteria, ICANN will confirm the buyer as the successor. Transition will be complete following notification to the community and registrar testing.

    8.4 ICANN will prepare a Request for Proposals (RFP) for a successor registry operator or sponsor. ICANN will schedule a Board meeting to discuss the transition and intent to seek a successor registry.

    8.5 For sTLDs, ICANN will seek input from the sponsored community on a successor. Applicants must meet certain successor criteria.

    8.6 ICANN will make an effort to post the RFP for at least 21 days, unless there is an urgent need for a shorter period of time.

    8.7 Elements of the RFP may consist of the following:

    • Application instructions
    • Application transmittal form
    • Proposal form
    • Financial Disclosure
    • Statement of Requested Confidential Treatment of Materials Submitted
    • Criteria to be used by ICANN to evaluate the proposals
    • Draft Registry Agreement, not including Appendices
    • If applicable, an application fee (with possible refund)
    • Description of what is being transferred

    8.8 ICANN shall post on its website the applications submitted in response to the RFP and provide sufficient time for public comment. There may be need to redact confidential/business proprietary information.

    8.9 ICANN shall conduct an evaluation of the applications and publish a staff recommendation and report.

    8.10 The staff recommendation and report will be provided to the ICANN Board for consideration and selection of the successor registry or sponsor.

    8.11 ICANN will coordinate with the registry or backend provider to ensure smooth transition of the TLD(s) to the successor registry.

    8.12 In the event that ICANN does not receive sufficient proposals to operate the sTLD, ICANN will publish a notice period to registrants and the community with a timeline on the impending closure of the TLD.

    8.13 ICANN will follow IANA's procedures for removing a TLD from the root zone.

  9. Non-voluntary Transition Process

    9.1 In the event that a registry or sponsor cannot continue operations and does not agree with ICANN on voluntary reassignment, ICANN will make a legal determination whether to proceed with the non-voluntary termination process. If the decision is made to proceed with the non-voluntary transition process, ICANN will invoke the breach process based on the terms of the registry agreement and provide notice to the registry or sponsor. The community will be informed of a decision to invoke the breach process.

    9.2 Under the terms of the gTLD registry agreement, ICANN must provide notice and opportunity to cure or initiate arbitration within thirty calendar days after ICANN gives registry or sponsor written notice of breach.

    9.3 In the event of a non-voluntary transition, ICANN may invoke the registry data escrow agreement and contact the third party escrow provider for a copy of all escrowed data related to the registry.

    9.4 The non-voluntary transition process will be managed by the Office of General Counsel.

  10. Closure of the registry

    10.1 In the event that the RFP fails to identify a successor registry operator or sponsor, ICANN will provide notice to the community and to registrants in the TLD(s).

    10.2 If possible, the registry, sponsor or backup registry operations provider will maintain operations for a designated period of time in order to ensure that registrants have sufficient time to locate alternatives to the TLD.

    10.3 After the designated period of time and notices to the community, the registry, sponsor or backup provider may terminate nameservers for the TLD.

    10.4 Following determination of the Board, termination of the TLD and notices to the community, ICANN will follow IANA procedures for removing a TLD from the root zone.

  11. Testing of Failover Plan

    11.1 ICANN shall test the registry failover plan and crisis communications plan on a periodic basis.

    11.2 Testing should be done in consultation with the Registry Constituency, and other members of the technical community. Testing may include registrars and third party data escrow providers. A joint panel of gTLD and ccTLD registry representatives may also provide assistance to ICANN in testing the registry failover plan.

  12. Failover Plan Review

    12.1 ICANN shall periodically review the failover plan and make modifications as necessary to stay current with registry practices.

    12.2 In the event of registry failure, ICANN will conduct a review of ICANN's handling of the event and document the lessons learned. ICANN will consult with SSAC, external experts and constituency advisory groups for their input on ICANN's handling of the event.

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"""" is not an IDN."