Skip to main content

Expedited Registry Security Request Process

This page was archived as of 23 May 2022. The current webpage can be found here.

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

The Expedited Registry Security Request (ERSR) has been developed to provide a process for gTLD registries who inform ICANN of a present or imminent security incident (hereinafter referred to as "Incident") to their TLD and/or the DNS to request a contractual waiver for actions it might take or has taken to mitigate or eliminate an Incident. A contractual waiver is an exemption from compliance with a specific provision of the Registry Agreement for the time period necessary to respond to the Incident. The ERSR has been designed to allow operational security to be maintained around an Incident while keeping relevant parties (e.g., ICANN, other affected providers, etc.) informed as appropriate.

An Incident could be one or more of the following:

  • Malicious activity involving the DNS of scale and severity that threatens systematic security, stability and resiliency of a TLD or the DNS;
  • Unauthorized disclosure, alteration, insertion or destruction of registry data, or the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards;
  • An occurrence with the potential to cause a temporary or long-term failure of one or more of the critical functions of a gTLD registry as defined in ICANN's gTLD Registry Continuity Plan [PDF, 96K].

The ERSR is exclusively for Incidents, i.e., requiring immediate action by the registry and an expedited response within 3 business days from ICANN. This process is not intended to replace requests that should be made through the Registry Services Evaluation Policy (RSEP).

It is recognized that in some extraordinary instances registries may be required to take immediate action to prevent or address an Incident. In cases of such Incidents, registries should submit an ERSR as soon as possible so ICANN may respond with a retroactive wavier if appropriate.

Registries can submit an ERSR by submitting a case via the Naming Service Portal. In the submission, the registry operator must indicate whether action has already been taken. The submitted request is processed as follows:

  • The ERSR will be forwarded to the ICANN Security Response Team. The Security Response Team includes staff from the following departments: SSR, GDD Operations, GDD Registry Services, GDD Technical Services, Legal and Compliance.
  • On a case-by-case basis, a designated member of The Security Response Team shall be responsible for contacting the Registry within 1 business day to confirm the Incident.
  • The Security Response Team may request additional information if necessary to review and consider the ERSR and the requestor will be asked to provide such information expeditiously.
  • The Security Response Team will discuss the request within 2 business days of the receipt of the request (and any requested additional information) to review and determine a response.
  • ICANN will respond verbally and in writing within 3 business days of receipt of the ERSR to the requestor or their designated representative.
  • A designated member of the Security Response Team will maintain contact with the Registry primary contact throughout the duration the Incident.
  • If the request is received after the Registry has responded to an Incident, ICANN will endeavor to respond within 10 business days to provide in writing a retroactive waiver to the request if appropriate.
  • Following a response to an ERSR, the Security Response Team in collaboration with the affected registry will develop an After-Action Report (AAR) that may be made available to the community. If an AAR is to be published, ICANN and the affected registry will jointly review which sections of the ERSR request and AAR should be redacted to ensure confidential and proprietary information is protected. ICANN and the registry can redact such information it reasonably considers confidential or proprietary.

Summary Analysis of Requests: 2019-2020

This section provides information on the outcomes of recent Expedited Registry Security Requests (ERSRs). ICANN org plans to update ERSR data on an annual basis.

Annual Number of ERSRs Processed

Waivers Issued 2019 2020
Total number of requests received 4 4
Number of generic top-level domains (gTLDs) covered by requests 8 6
Number of new waivers issued 1 4
Number of waivers not granted 0 0
Number of requests deemed in scope of an existing waiver 3 0
Number of requests resulted in an update to an existing waiver 0 0

ERSR Details

Metrics 2019 2020
Approximate number of domain names subject to the request* 5,600 domain names 1,600 domain names
Number of requests made in advance of action taken on the domain names 4 3
Number of requests made after action was taken on the domain names 0 1

* Note: These numbers do not include ongoing actions such as those taken by registry operators, law enforcement agencies, and closed court orders.

Average Processing Duration

The below metrics show the average time it took for ICANN org to process an ERSR, from submission of a fully completed questionnaire through to the registry operator receiving a response from ICANN org.

Waiver Response 2019 2020
Issuance of the waiver 2 business days 4 business days
Notification the waiver is not granted N/A N/A
Notification the request in scope of an existing waiver 1 business day N/A
Issuance of updated existing waiver N/A N/A
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."