Skip to main content
Resources

Material Subcontracting Arrangement (MSA) Change

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.

Overview

This webpage provides guidance for registry operators on requesting ICANN org approval of a Material Subcontracting Arrangement (MSA) change.

Any subcontracting arrangement related to any Critical Function as defined in Specification 10, Section 6 of the Registry Agreement is considered a Material Subcontracting Arrangement (MSA). Subcontractors that operate one or more Critical Function(s) are referred to as either a Back-End Registry Operator or Registry Service Provider (RSP).

Critical Functions subject to the MSA change process include:

  • DNS resolution
  • 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., Registration Data Access Protocol (RDAP) and WHOIS provided over both port 43 and through a web-based service.

Through the MSA change process, ICANN org tests and evaluates an RSP to ensure it has the capacity to operate a top-level domain (TLD) in a stable and secure manner. ICANN org also requires registry operators to submit a transition plan to demonstrate how a transition of services from one RSP to another will be coordinated and completed in a stable and secure manner.

Below is a general timeline of the MSA process. Click here for a more detailed process workflow.

Material Subcontracting Arrangement (MSA): Change Request Timeline

Before You Submit: Considerations and Preparations

The steps below highlight key considerations and preparations registries should make prior to submitting an MSA change request in the Naming Services portal (NSp).

Step 1: Take into account related transactions Changing your RSP could result in other associated changes. Consider for instance:

  • Will you be making any modifications to the Registry Services in Exhibit A of the Registry Agreement (RA) as a result of your RSP change?
  • Will you be assigning the TLD to a different entity in addition to this MSA change?

Modifications to Registry Services: If your proposed RSP offers different Registry Services than your current RSP (e.g., Registry Lock, IDN languages/scripts), you will need to update your Exhibit A language by submitting a Registry Services Evaluation Policy (RSEP) request in advance of the MSA change request submission. We encourage you to request a consultation call to discuss the appropriate steps.

Assigning the TLD: If you plan on assigning the TLD RA to a different entity in addition to your MSA change, you'll need to complete one transaction before initiating the other. We strongly recommend you request a consultation call to discuss available options and help you better understand the transactional implications. View the Assignments page for more information about assigning a TLD.

Step 2: Understand your timeline. Allow yourself at least 7-12 weeks to complete the MSA change request with ICANN org. Factor into your timeline the requirements for ICANN org to process the MSA change, including testing, in relation to your business needs and requirements. For example, consider:

  • Is your agreement with your current RSP ending soon?
  • How long will it take to transition from your current RSP to the new RSP?

Step 3: Organize a consultation call with your Account Manager to ensure you understand the process. Your Account Manager can provide a general overview of what the process involves, inform you of required documentation and testing, and help ensure you understand what is needed to initiate an MSA change request. This will make the process more efficient once you are prepared to submit your request.

Step 4: Review and prepare the required documentation. Plan ahead by reviewing resources provided and preparing the documentation you will need to include in your submission, taking note of the following:

  • Review the Registry System Testing page and resources.
  • Determine if your proposed RSP is a new (unknown) RSP or an existing (known) RSP. An unknown RSP is a provider not currently supporting one or more new generic top-level domains (gTLDs).
  • For an unknown RSP, you must submit responses to: MSA Technical Questions. There are additional reviews, testing, and steps to take if you are looking to transition to an unknown RSP. See the MSA Change Guide for further details on additional requirements.
  • Develop a Transition Plan (reference the Transition Plan Guidelines).
  • Understand the fees associated with the type of MSA change you are requesting (change to an unknown RSP or change to a known RSP).
  • View the MSA Change Process Workflow.

Resources

Requirements at a Glance (by MSA change type)

Requirement Known RSP Unknown* RSP

Informal Submission

Technical Evaluation

($14,300 USD est. evaluation cost)

 

Transition Plan Approval

Registry System Testing

Simulation Exercise

 

Formal Submission/ICANN Review

ICANN Determination

RSP Transition

*Does not currently support new gTLDs

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