Skip to main content

Expedited Registry Security Request Process

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 completing a request form found at The submitted request is processed as follows:

  • The ERSR will automatically be forwarded to the ICANN Security Response Team and a copy will be provided to the requestor. The Security Response Team includes staff from the following departments: Security, gTLD Registry Liaison, General Counsel 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 and request if necessary additional information.
  • 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 convene 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.
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."