Skip to main content

Frequently Asked Questions: Name Collision Occurrence Management Framework for Registries

Controlled Interruption, and Wildcards
Contractual Compliance
Emergency Response
Application Processing
Second-Level Domain Blocking & Alternate Path to Delegation


Q1: What is a name collision?

A1: A name collision occurs when an attempt to resolve a name that is used in a private name space (e.g. under a non-delegated top-level domain (TLD) or a short, unqualified name) results in the resolution of a DNS query to the public domain name system (DNS). For an analogy, consider calling for "Mary" in your office where there's only one "Mary", and then calling out "Mary" in a shopping mall and expecting that "office Mary" will respond.

Q2: What is the Name Collision Occurrence Management Framework?

A2: The Name Collision Occurrence Management Framework [PDF, 634 KB] is a set of requirements developed to manage the name collision occurrences between new gTLDs and existing private uses of the same strings. It was developed with input from many sources including the ICANN community, a report published by JAS Global Advisors LLC, and the Security and Stability Advisory Committee (SSAC).

Q3. What are key features specified in the framework?

A3: Key features include:

  • New generic top-level domain (gTLD) registry operators will implement controlled interruption for a continuous period of no less than 90 days.
  • ICANN will monitor each registry's implementation of the controlled interruption to ensure compliance with contractual requirements.
  • Name collision emergency responses may be triggered in situations where there is a reasonable belief that the name collision presents a clear and present danger to human life.
  • ICANN is prepared to respond to potential emergency situations.

Q4: What are the next steps for registry operators?

A4: ICANN will issue each registry operator a Name Collision Occurrence Assessment, which is the mechanism used to instruct the registry about the required mitigation measures from the final Name Collision Occurrence Management Framework. The assessment will include details about how controlled interruption must be implemented.

Q5: How does ICANN plan to implement the 90-day community consultation on rights protection mechanisms as directed by the Board resolution?

A5: The consultation concerns treatment of names included in a registry operator's Alternate Path to Delegation Report and recorded in the Trademark Clearinghouse that registry operator withheld from allocation during its Sunrise period or Claims period. ICANN will open a public comment period on this topic and is developing a paper describing the current requirements, the feedback received to date, and the alternatives for handling of these names.


Controlled Interruption, and Wildcards

Q6: What is controlled interruption?

A6: Controlled interruption is a method of notifying system administrators who have configured their networks incorrectly (knowingly or unknowingly) of the namespace collision issue, and helping them mitigate potential issues.

Q7: How does controlled interruption work?

A7: Controlled interruption is an approach to catch errant DNS queries. When an errant query is caught, a registry takes a "controlled" action to prevent harm and alert the user that a fix is needed. That action takes the form of responding to the DNS query with a special IP address ( The word "interruption" refers to an activity that once seemed to work despite the errant query, but is now prevented from working.

Q8: How will controlled interruption be implemented?

A8: New gTLD registries will implement the controlled interruption by placing a specific set of resource records into the DNS. These resource records have been selected to hint to system administrators that they should diagnose and correct their systems to prevent potential issues in the future. The listing of specific records can be found in the Name Collision Occurrence Management Framework [PDF, 634 KB].

Q9: When does the 90-day controlled interruption period start?

A9: Registry operators may start the controlled interruption as early as 18 August 2014 provided they have received their Name Collision Occurrence Assessment (ICANN will begin issuing assessments on 4 August 2014).

Q10: Can a registry start the controlled interruption period earlier?

A10: Implementing a controlled interruption period before the 18 August 2014 date will not count towards the 90-day continuous controlled interruption period required for each TLD.

Q11: What is

A11: is a special IPv4 address that will appear in system logs alerting system administrators that there is a potential name collision issue, enabling a quick diagnosis and remediation. The "53" is used as a mnemonic to indicate a DNS-related problem owing to the use of network port 53 for the DNS service. Instances where there is a reasonable belief of demonstrable severe harm as a consequence of a name collision should be reported at Additional information on name collision can be found at

Q12: What about controlled interruption for IPv6 addresses?

A12: ICANN will work within the Internet Engineering Task Force (IETF) and with other relevant technical communities to identify a mechanism for IPv6 that provides similar functionality to that being used in IPv4 (the loopback address

Q13: Why was continuous controlled interruption selected as the preferred method for name collision mitigation instead of intermittent interruption?

A13: Continuous controlled interruption is a simpler approach operationally and provides for a consistent way to diagnose and troubleshoot, which results in a greater likelihood of the collision being recognized, diagnosed, and mitigated.

Q14: Why is there a wildcard option? Aren't they prohibited?

A14: The prohibition against wildcards is waived for the controlled interruption period for applicable TLDs (i.e., where there are no active names under the TLD other than "nic"). This waiver only applies while there are no names delegated (hence, operational) within that TLD, removing the risks that are traditionally associated with wildcard implementations. The reason for lifting the prohibition and specifying the use of the wildcard is to catch all evident name collision situations. The wildcard at the "top" of the zone will match all of the queries that will ever be seen once the zone runs in full production. This approach maximizes the steps taken to protect Internet users that are currently leaking queries that are meant to be local.


Contractual Compliance

Q15: How will ICANN ensure that registries comply with these new requirements?

A15: ICANN will monitor the implementation of the requirements, primarily using the zone files that are transferred to ICANN from new gTLD registries once they are delegated (per Specification 4 of the New gTLD Registry Agreement). This requirement will be enforced, just like other registry agreement provisions, by ICANN's Contractual Compliance department.

Q16: How will a registry know if it has implemented the Name Collision Occurrence Management Framework requirements correctly?

A16: ICANN will monitor each registry's implementation of the requirements found in the Name Collision Occurrence Management Framework [PDF, 634 KB]. ICANN will notify the registry of errors that need to be fixed.


Emergency Response

Q17: What type of name collision event warrants an emergency response?

A17: An emergency response can be triggered when there is a reasonable belief that the name collision presents a clear and present danger to human life.

Q18: Who will decide what constitutes an emergency?

A18: ICANN will assess the potential harm in accordance with the standard defined in the Name Collision Occurrence Management Framework.

Q19: Who will manage and monitor emergency response requests?

A19: ICANN will act as the single point of contact for emergency response request/reports, coordinate notification to the relevant registry operator and ensure that appropriate action is taken in an expeditious manner.

Q20: How do I report an emergency?

A20: Emergency response requests should be submitted online at


Application Processing

Q21: Will the requirements to implement the controlled interruption after delegation impact Pre-Delegation Testing (PDT)?

A21: Pre-Delegation Testing will not be modified at this time to incorporate testing for the implementation of controlled interruption. In fact, a registry should NOT implement controlled interruption for their PDT appointment.

Q22: What is the status of applications for .CORP, .HOME and .MAIL?

A22: The delegation of .CORP, .HOME and .MAIL has been deferred indefinitely. ICANN will collaborate with the technical and security communities to determine the best way to handle these strings in the long term.

Q23: I am currently scheduled for an auction. Will the release of the Name Collision Occurrence Management Framework affect my auction date?

A23: No, the Name Collision Occurrence Management Framework will not affect the date of auctions currently scheduled. View the current schedule on the Auctions page of the new gTLD website, or find the auction date for an unresolved contention set on the Contention Set Status page.


Second-Level Domain Blocking & Alternate Path to Delegation

Q24: What should be done with the names in the SLD block list when they are released in regards to TMCH Sunrise and Claims?

A24: Registry Operators must ensure that names desired to be activated from its SLD Block List after the 90-day controlled interruption period have been subject to applicable Rights Protection Mechanisms as required under Specification 7 of its Registry Agreement. The Name Collision Occurrence Assessment provides additional clarification on the matter.

Additionally, consistent with NGPC's action 30 July 2014, for names included on the block list of the registry's Alternate Path to Delegation Report and recorded in the Trademark Clearinghouse that the registry withheld from allocation during its Sunrise Period or Claims Period, the registry must continue to withhold the names from allocation while ICANN consults with the community about concerns expressed regarding appropriate rights protection mechanisms for this category of names.

Q25: Is the Alternate Path to Delegation still an option now that the Name Collision Occurrence Management Framework is completed?

A25: No. Registries must activate name in accordance with requirements specified in the Name Collision Occurrence Management Framework. Those TLDs delegated prior to 18 August 2014 that have not activated second-level domain names (other than "nic") will have the option to do wildcarded controlled interruption.

Q26: What happens to the 25 gTLDs that were not eligible for the alternate path to delegation?

A26: Once the applicant has completed all previous stages of the program, these 25 strings (with the exception of .MAIL) are now able to proceed to delegation by implementing controlled interruption consistent with the Name Collision Occurrence Management Framework (i.e. using the wildcard method.) More information is available at


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."