Skip to main content

Non-Lawyers' Guide to the May 2009 Registrar Accreditation Agreement*

This page was archived as of 14 August 2018. Information about the current version of the Registrar Accreditation Agreement is here.

Non-Lawyers' Guide to the May 2009 Registrar Accreditation Agreement [PDF, 136 KB]


This document is being produced in response to the At-Large Advisory Committee's (ALAC) request for a Non-Lawyers' Guide to ICANN's Registrar Accreditation Agreement (RAA), at As noted in the request, the RAA is a legal document entered into between ICANN and Registrars, drafted under California law. As a result, those that are not party to this agreement, who are unfamiliar with the United States legal system, non-lawyers, and/or non-native English speakers may have difficulty understanding the obligations ICANN and the Registrars have agreed to. This guide does not alter or amend the RAA in any way, and is not a legal interpretation of the RAA.

This guide provides a basic summary of the May 2009 RAA (available at Some registrars are still operating under the May 2001 RAA, (available at, so some of the items discussed here will not apply to all registrars at this time. You can see which registrars are working under the 2009 RAA by reviewing the Accredited Registrar list (available at The RAA applicable to each registrar is identified in the “RAA” column.

To assist in the reading of this Guide, a short Glossary is included at the end of the document.

1. Overview

The RAA is one part of the domain name registration process. Briefly, ICANN contracts with Registry Operators, the companies that run gTLDs. If a customer wants to register a domain name in a gTLD, a customer must go through an ICANN-accredited Registrar – a company that enters into the RAA with ICANN. When a customer registers a domain name, the customer provides the Registrar with information such as billing and contact information, as well as name server information for the operation of the domain name. The Registrar then transmits this information to the Registry Operator so that the name will resolve within the domain name system. Each domain name registration is for a limited time. The shortest registration term offered by Registrars is one year, and registrations can be made for up to ten years at a time. When a registration term expires, the Registered Name Holder may renew the registration. If a Registered Name Holder does not agree to renew the registration, the Registered Name Holder generally will lose the right to the domain name, and the domain name will be available for another customer to register. When the registration term expires and is not renewed, the domain name may ultimately be deleted by the Registrar, and the domain name will no longer resolve.

In order for a Registrar to be accredited by ICANN, the Registrar has to apply for accreditation, a process that is described in detail at Briefly, the company applying for accreditation has to provide ICANN with information on business, technical and financial matters. The applicant has to also provide information on the persons who are the officers, directors and managers of the company. If the application is successful, the Registrar must, among other things, sign ICANN's standard RAA in order to complete the accreditation process.

Every ICANN-accredited Registrar must enter into the standard RAA with ICANN to offer registration functions in gTLDs. The RAA consists of multiple parts: (1) the main agreement; (2) appendices for each TLD the Registrar is accredited to operate within; and (3) the ICANN Logo License Appendix, which gives the accredited Registrar permission to use a special “ICANN Accredited Registrar” logo on the Registrar's site. While the main agreement and the Logo License Appendix are standard for each Registrar, Registrars can, but choose to not enter into every available TLD appendix. For example, a Registrar may decide to offer registrations in only a few of the available TLDs, such as.COM,.NET and.INFO, and to not offer registrations in other TLDs. In such a case, the Registrar may choose to only enter into TLD appendices for.COM,.NET and.INFO, though the Registrar may elect to add additional TLDs at a later time. A listing is available showing every TLD that each Registrar is accredited to offer registration services in, at In this Guide, the term “relevant TLD” will refer to a TLD that a Registrar is accredited to offer services within. A Registrar will typically have a separate agreement with each Registry Operator that the Registrar is accredited within, and that agreement may include additional Registrar obligations.

Registrars may not make claims that they can provide Registered Name Holders with superior access to any relevant TLD in comparison to other Registrars.

Some ICANN-accredited Registrars may offer registration services for country code Top Level Domains (ccTLDs) such as.DE,.UK, and.ME. ICANN does not accredit registrars for ccTLDs, and the requirements of the RAA do not apply for registrations within those ccTLDs. Accreditation of registrars for ccTLDs is a matter of choice for the ccTLD Registry Operators – ccTLDs do not have to accredit registrars, and if they choose to accredit, ccTLDs may set their own standards and obligations for accreditation.

The RAA is a two-way street. In other words, both ICANN and the Registrar make commitments to each other in the agreement, and ICANN and the Registrar can each violate the agreement. Either ICANN or the registrar may be held liable for failure to comply with their respective obligations.

As the RAA is between ICANN and a Registrar, no one else – including a Registered Name Holder – may sue ICANN or the Registrar to claim a violation of the RAA.

2. The RAA

The main agreement is divided into five sections:

  1. Definitions
  2. ICANN Obligations
  3. Registrar Obligations
  4. Procedures For Establishment Or Revision Of Specifications And Policies
  5. Miscellaneous Provisions

While this guide generally follows the sections as set out in the RAA, some of the provisions are interrelated. This guide follows the discussion by topic, not necessarily as a section-by-section outline of the provisions.

2.1 Definitions

The Definition section lays out certain terms that are used throughout the RAA. Without attempting to re-state all the definitions from this section, some key terms are described in the Glossary included at the end of this Guide.

2.2 ICANN Obligations

Briefly, ICANN's obligations include providing the accreditation and granting the Registrar a license to state that the Registrar is accredited by ICANN. Registrars may request accreditation in additional TLDs during the term of the agreement. ICANN is also obligated to act in an open and transparent manner, apply standards equitably among Registrars, not restrain competition, and assure that a Registrar has adequate appeal procedures within ICANN.

2.3 Registrar Obligations

As the Registrar Obligations section of the RAA contains many provisions detailing Registrars' obligations in relation to dealings with Registered Name Holders, this section of the Guide provides more detail than is provided within other sections.

Registrars have some basic obligations, such as Registrars are bound to follow ICANN policies and consensus policies, and to operate in accordance with the law. The RAA also specifically requires Registrars to abide by the Uniform Domain Name Dispute Resolution Policy, commonly referred to as the UDRP.

Registrars also have specific items on which they must provide notice to Registered Name Holders, including notifications of the end of a registration term, use of Registered Name Holder's Personal Data, and in some cases notices regarding escrowing of data for domain names registered through privacy or proxy registration services, described below. Registrars are also required to post fees charged for recovery of registered names.

2.3.1 Registrar Submission of Data to Registry Operators

For each relevant TLD, Registrars must submit certain data points relating to each Registered Name within a TLD: The name of the Registered Name being registered; The Internet Protocol (IP) addresses of the primary nameserver and secondary nameserver(s) for the Registered Name; The corresponding names of those nameservers; Unless automatically generated by the registry system, the identity of the Registrar; Unless automatically generated by the registry system, the expiration date of the registration; and Any other data the Registry Operator requires be submitted to it.

Registered Name Holders are normally required to provide the Registrar with information relating to nameservers ( – 3), and there may be additional data required under Section that the Registered Name Holder must provide. If the Registered Name Holder provides an update on these data points, the Registrar has five (5) days to provide the update to the Registry Operator.

The Registrars are also required to provide ICANN with an electronic database of all the data elements for all active registrations within a TLD if ICANN requests in the event of a technical failure or change in Registry Operator.

2.3.2 Whois Data

The background of Whois services is not discussed in the RAA. For context, Registrars are required to make available specific contact and technical information related to every domain name registration under the Registrar's accreditation. That information, the Whois data, has to be publicly available, in a specific format and available on a designated “port” reserved for Whois data sharing, port 43, as well as on an interactive webpage. The Whois service is a tool used for many purposes, such as determining whether a domain name is available for registration, identifying the registrant of a domain name that has been associated with malicious activities, contacting domain name registrants on matters related to trademark protection, and verifying online merchants, to name a few.

Registrars are required to have an interactive web page and the port 43 Whois service available to the public to query free of charge. The RAA specifies certain data points that must be provided in response to a query: The Registered Name; The names of the primary nameserver and secondary nameserver(s) for the Registered Name; The identity of Registrar (which may be provided through Registrar's website); The original creation date of the registration; The expiration date of the registration; The name and postal address of the Registered Name Holder; The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name.

These data points are commonly referred to as Whois data. As discussed below, Registered Name Holders are required to provide a Registrar with timely updates to Whois data for a Registered Name. Upon receiving the update, a Registrar is to promptly update the Whois data. Registrars may contract out the maintenance of the public query function to a third party.

The RAA requires Registrars to provide bulk access to Whois data to third parties. When providing bulk access or access to the Whois data through the public query function, the Registrar is required to restrict use for high volume queries and other restrictions on uses of Whois data as specified in the RAA, including marketing activities and mass solicitations.

2.3.3 Communications with Registered Name Holders

Registrars are required to maintain records of all communications with Registered Name Holders, as well as records of information provided to Registry Operators.

2.3.4 Escrow of Registered Name Holder Data

A Registrar is required to maintain a database of all Whois data for all Registered Names registered through the Registrar's accreditation, as well as all data the Registrar submits to the Registry Operator. In addition, the Registrar must include in the database the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact for each Registered Name.

The Registrar is required to escrow – or deposit with a third party in trust – this complete database of data, referred to as “data escrow.” The database may be released from escrow to assist the Registrar, ICANN or an assignee, if necessary, to provide Registrar Services. ICANN, the Registrar, and the data escrow company enter into an additional contract to specifically govern the terms of the data escrow process, a model of which is at [PDF, 45 KB].

By way of background, there are some instances in which, a customer wanting to use a domain name might want to limit the amount of personal information that a Registrar makes available in a Whois query. To do so, the domain name may be registered through a privacy service (allowing a Registered Name Holder to replace some personal identifying information with the privacy service's information, such as using the privacy service's P.O. Box in place of the Registered Name Holder's home or business address) or a proxy service, a service that registers the domain name and licenses the use of the domain name to a customer. When a proxy service is used, the proxy service is the Registered Name Holder, and therefore the proxy service's information is used for most or all of the required data points.1 Despite that fact that the RAA includes provisions relating to the use of privacy or proxy services, ICANN has never taken a position in favor of or in opposition to privacy or proxy services.

When a Registered Name is registered through a privacy or proxy registration service, that affects the information that is placed in the database, the RAA requires that a Registrar offering a privacy or proxy service must do one of two things: The Registrar must either (1) include in the database the customer's name and postal address, e-mail address, and voice telephone number in addition to the proxy or privacy registration service's information, or (2) at the time that a customer elects to use a privacy or proxy registration service, display a notice that the customer's data is not being escrowed. When a customer's data is not being escrowed, only the contact information associated with the privacy or proxy registration service will be escrowed. If a customer's data is not escrowed and only the information of the proxy or privacy service is maintained in the database, in the event of Registrar or Registry failure future notices might only be sent to the contact information of the privacy or proxy service and not to the customer.

ICANN has rights to access and review the data the Registrar is required to maintain. However, ICANN is restricted from disclosing the contents of the data except as allowed by an ICANN specification or policy.

2.3.5 Registrar Business Dealings with Registered Name Holders

The RAA imposes many requirements on a Registrar's business dealings, including its dealings with Registered Name Holders.

Section 3.7.4 of the RAA requires that a Registrar may not activate a Registered Name until it receives reasonable assurance that the registration fee will be paid.

The RAA describes the actions the Registrar may take at the conclusion of the registration period if a Registered Name Holder has not provided consent to renew the registration, including the Registrar cancelling the registration at the end of the current registration term. If the Registered Name Holder or someone acting on behalf of the Registered Name Holder did not consent to renewal, the Registrar must make sure that a Registered Name is deleted from the Registry database within 45 days of the end of the registration term.

This obligation to delete the domain name is not absolute. Section of the RAA sets forth a list of potential “extenuating circumstances,” that, when they pertain, allow the Registrar to renew the domain name even without the consent of the Registered Name Holder. These circumstances include the Registered Name being subject to a UDRP 2 action, court order, bankruptcy proceeding, or billing dispute, among other items. The Registrar must keep a record of reasons why the Registrar renewed a registration without the consent of a Registered Name Holder. Registrars also have the ability to insert additional terms into their agreements with Registered Name Holders that modify the Registrar's deletion requirements.

Registrars have to provide each new Registered Name Holder with notice of the Registrar's deletion and auto-renewal policies. If the Registrar's deletion policy changes during the time of the registration agreement, the Registrar has to make efforts to inform the Registered Name Holders of those policy changes. Details of the deletion and auto-renewal policies have to be displayed on any website the Registrar operates for domain name registration and renewal, and the Registrar should also state on those sites any fee that will be charged for the recovery of a domain name during the Redemption Grace Period (the 30-day period of time during which the name is in “Pending Delete” status with the Registry).3

If a Registered Name is the subject of a UDRP dispute at the time of deletion or expiration of the registration, the UDRP complainant has the right to renew (or restore, in the case of a deletion) the domain name. If the complainant renews or restores the name, the Registrar must place the name in a HOLD or LOCK status,4 and must modify the Whois information to show that the name is subject to dispute. Section of the RAA also provides for a right for the original Registered Name Holder to recover or renew the name in the event the UDRP complaint is terminated without decision, or the UDRP complaint is decided in favor of the original Registered Name Holder. The Registrar/Registered Name Holder Agreement

Registrars are required to enter into electronic or paper registration agreements with all Registered Name Holders. According to the RAA, the Registrar/Registered Name Holder Agreement must include – at minimum – the following items (as stated at Sections – 12 of the RAA):

  • The Registered Name Holder must provide “accurate and reliable contact details” and must “promptly correct and update them” during the registration term. The details required are stated in Section “the full name, postal address, e-mail address, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person for contact purposes in the case of a Registered Name Holder that is an organization, association, or corporation; and the data elements listed in Subsections, and”
  • If a Registered Name Holder intentionally provides inaccurate or unreliable information, intentionally fails to promptly update the information, or fails to respond within fifteen (15) days to Registrar inquiries about the accuracy of the contact details, the Registered Name Holder will be in material breach of the agreement and the registration may be cancelled.
  • Whoever is listed as the Registered Name Holder must provide full contact information, and is the Registered Name Holder of record. Sometimes a Registered Name Holder may register a domain name and then allow another person to use the domain name (such as a website designer registering a domain name for a client). If this happens, and the person actually using the name did not enter into the Registrar/Registered Name Holder Agreement (referred to as a “third party” in the RAA), the Registered Name Holder could be accountable for wrongful use of the domain name by the third party. This will happen if the Registered Name Holder is provided with “reasonable evidence of actionable harm” from the third party's use of the domain name. In that situation the Registered Name Holder will “accept liability for harm caused by wrongful use of the Registered Name,” unless the Registered Name Holder promptly discloses the user's identity and current contact information provided by the end user.
  • The Registrar must provide notice of how it intends to use data provided by the Registered Name Holder and who will receive the Registered Name Holder's data. The Registrar must also provide notice of how Registered Name Holders may access and update data. Additionally, the Registrar must identify which data points the Registered Name Holder must provide to the Registrar, and what information can be provided on a voluntary basis. The Registered Name Holder must consent to all of these data processing terms.
  • If a Registered Name Holder provides the Registrar with Personal Data on behalf of any person who did not enter into the Registrar/Registered Name Holder Agreement (the “third party” discussed above), the Registered Name Holder must confirm that it (1) provided those third-party individuals with the same data processing notices that the Registrar provides, and (2) received the same consents from the third party regarding the Registrar's data processing terms.
  • A Registrar may only process the Registered Name Holder's data as stated in the data processing notices described above.
  • A Registrar has to agree that it will take reasonable precautions to protect the Registered Name Holder's data from “loss, misuse, unauthorized access or disclosure, alteration, or destruction.”
  • Registered Name Holders must represent that: “to the best of the Registered Name Holder's knowledge and belief, neither the registration of the Registered Name nor the manner in which it is directly or indirectly used infringes the legal rights of any third party.” This means that the Registered Name Holder must represent to the Registrar that the domain name is not being registered for use in a way that would violate the legal rights of others. An example of this “infringement” could be a registration of a domain name that infringes a trademark held by someone that is not the Registered Name Holder.5
  • If there is a dispute in connection with the use of the registered name, the Registered Name Holder must agree to jurisdiction of the courts both where the Registrar is located (often stated on the website or in the Registrar/Registered Name Holder Agreement) and the courts of the “Registered Name Holder's domicile.” “Domicile” is a word with legally-specific meaning, but typically will be the location the Registered Name Holder provides to the Registrar in the required Personal Data. Agreeing to jurisdiction means that the Registered Name Holder agrees that the courts in either of those locations have the power to decide these types of cases.6
  • The Registered Name Holder must agree that its registration is subject to “suspension, cancellation, or transfer” for the reasons stated in Section Those reasons include: if an ICANN adopted specification or policy requires it or if a registrar or registry procedure requires it “to correct mistakes by Registrar or the Registry Operator in registering the name or for the resolution of disputes concerning the Registered Name.” For example, the UDRP is an ICANN adopted policy that specifies that an administrative panel hearing a domain name dispute could order that a domain name registration be suspended, transferred or cancelled, and the Registered Name Holder has to agree that this is a possibility.
  • The Registered Name Holder shall “indemnify and hold harmless the Registry Operator and its directors, officers, employees, and agents from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable legal fees and expenses) arising out of or related to the Registered Name Holder's domain name registration.” At its simplest, this means that if the Registry Operator (or its employees, etc.) for the registered name is sued because of the Registered Name Holder's domain name registration, the Registered Name Holder will pay the Registry Operator for all fees and expenses in defending against the suit as well as pay for any judgments or liabilities awarded. This “indemnification” is not solely limited to court cases.
  • Verification of contact information

As described in more detail below, there are specifications and policies that may be created and that apply to the Registrars. Some of the specifications or policies may address a Registrar's obligation to verify the contact information supplied by the Registered Name Holder when the domain is first registered, as well as setting out requirements for periodic re-verification of contact information. Registrars are required to follow any such specifications and policies provided they are commercially practicable.

Registrars are also required to take “reasonable steps” to verify contact information in the event any person notifies the Registrar that contact information for a Registered Name is inaccurate. The Registrar also has obligations to act to correct inaccuracies in contact information that the Registrar becomes aware of, even if the inaccuracy was not reported by anyone.

The Registrar must also maintain proper contact information for itself, including a valid email and mailing address. This contact information must be posted on the Registrar's website. Registration Service fees

The RAA does not impose limitations on the fees that Registrars may charge to Registered Name Holders for registration services.

2.3.6 Registrar Fees to ICANN

The RAA specifies that Registrars are obligated to pay to ICANN annual fees as well as variable fees. The RAA sets out the terms of payment of fees.

2.3.7 Registrar Obligations for the Acts of Others Common controlling interest

When entities apply for accreditation, they are required to provide ICANN with information about the ownership and management of the proposed Registrar. It has become common for multiple companies sharing a common controlling interest (such as the same “parent” company or same persons listed as owners) to apply for separate accreditation. These Registrars are separate legal entities with separate RAAs, however the May 2009 RAA adds some additional obligations on the Affiliated Registrars because of the close relationship between the affiliated companies. Not all Registrars have Affiliated Registrars.

The RAA sets out conditions where a Registrar under a common controlling interest with its Affiliated Registrars will be in breach of the RAA based on the acts of two or more of those Affiliated Registrars. Reseller arrangements

The 2009 RAA also imposes new obligations on Registrars working with Resellers – persons or entities that the Registrar contracts with to bring in customers and in some cases to provide some registrar services. The 2009 RAA requires Registrars to include specific items in the Registrar/Reseller Agreements, including: prohibiting the Reseller from making representations that it is accredited by ICANN; requiring that all Reseller registration agreements include all provisions that the Registrar is required to include in its Registrar/Registered Name Holder Agreement; requiring the posting of all links to all ICANN websites that the Registrar is obligated to post; and identification of the sponsoring Registrar. The Reseller is also required to make sure that that if a customer is using a Reseller's privacy or proxy registration service for a domain name registration, the Reseller does one of the following three things: (1) deposit the identity and contact information of the customer with the Registrar; (2) deposit the identity and contact information in escrow; or (3) post a notice to the customer that their contact information is not being escrowed.

The RAA also requires the Registrar to take compliance and enforcement action against a Reseller violating any of the required provisions.

2.3.8 Registrar Cooperation with ICANN

Registrars will now be required to complete a training course, developed in consultation with Registrars and provided by ICANN, on Registrar obligations. Upon reasonable notice (set out in the RAA), Registrars are also required to cooperate with ICANN compliance audits, provide information to ICANN in a timely fashion, and allow requested physical site visits by ICANN, as well as independent third-party accounting verification audits of Registrar's books and records. In addition, if ICANN, in consultation with Registrars, creates content identifying Registered Name Holder rights and responsibilities, the Registrars are required to post a link to the webpage containing that content.

2.4 Procedures For Establishment Or Revision Of Specifications And Policies

As mentioned above, Registrars are required to comply with ICANN specifications and policies, including those that are established or revised during the term of the RAA. The RAA sets out the topics of specifications and policies that may be later established and revised, including items related to the interoperability and stability of the DNS, resolution of domain name disputes, allocation of registered names, and prohibitions on Registrar warehousing of registered names. The topics are specific and are not easily summarized or condensed; however the important point is that there are many areas where a Registrar has ongoing obligations to comply with revisions and new specifications and policies created during the term of the RAA, even if the terms of those specifications and policies are not specifically written into the RAA. ICANN must provide the Registrar a reasonable period of time after notice is given to comply with a newly established specification or policy.

Some of these specifications and policies are referred to as “Consensus Policies”, and are established “based on a consensus among Internet stakeholders represented in the ICANN process.” The Registrar is required to follow these Consensus Policies just as the Registrar is required to follow other ICANN specifications and policies. There may be times, however, when the Registrar does not believe that “consensus” existed to support the creation of the policy, and therefore believes that it does not have to comply with the Consensus Policy. The RAA therefore sets out a procedure for a Registrar to dispute whether consensus exists, and therefore whether the Registrar is required to follow the specification or policy at issue. Sections 4.3 and 4.4 of the RAA contain a substantial amount of very specific information related to the creation of Consensus Policies and the timing of the dispute process.7

2.5 Miscellaneous Provisions

Section 5 of the RAA sets out a variety of provisions that mainly focus on the resolution of disputes under the RAA, the termination of the RAA, and the type of relief that ICANN or the Registrar may seek through a lawsuit or arbitration that is initiated under the RAA. Some of the notable portions of Section 5 are:

2.5.1 Termination

The RAA has a five (5) year term, and if a Registrar requests to renew its RAA at the end of the five year term, ICANN will allow a renewal, but only if the Registrar is in compliance with its obligations under the RAA. As happened in 2009, there is the possibility that the RAA may be revised again. If that happens, the Registrar may request to – but does not have to – enter into the “new” RAA, even if the Registrar's current agreement has not yet ended. When the five-year term expires and the Registrar renews the RAA, the Registrar will have to enter into the most recent version of the RAA available at the time of renewal.

A Registrar may terminate the RAA at any time prior to the termination of the RAA by giving ICANN thirty (30) days written notice.8

ICANN may only terminate the RAA under the specific circumstances set out under Section 5.3, including if a Registrar: makes material misrepresentations in its application for accreditation; faces a conviction or legal judgment related to fraud or similar offenses; is subject to governmental discipline for the misuse of the funds of others; and fails to cure a breach of the RAA that was identified in a notice of breach from ICANN. ICANN also may terminate a Registrar's accreditation when the Registrar becomes bankrupt or insolvent, or when the Registrar is engaging in action that ICANN determines to endanger the operational stability of the Internet. In all situations other than insolvency, ICANN must give fifteen (15) days notice of the termination. For situations involving the operational stability of the Internet, ICANN may suspend an RAA for up to five (5) days while ICANN seeks emergency relief from the courts.

If a Registrar receives a termination notice, the Registrar may challenge the termination through the filing of an arbitration.9A Registrar may also request that the arbitrators stay the termination – in other words, allowing the Registrar to continue operating as an accredited Registrar – until a final decision is made in the arbitration. The arbitrators may only issue a stay and allow the Registrar to continue its business if it is shown that the continued operation of the Registrar would not be harmful to consumers or the public interest, or if the arbitrators identify a separate manager (not associated with ICANN or the Registrar) to manage the Registrar operations until the arbitrators issue a decision. Unlike previous versions of the RAA, ICANN may ask the arbitrators to “lift” the stay and terminate Registrar operations before the arbitration is completed. The RAA sets out additional requirements on how and where the arbitration is to be conducted. In addition, the RAA allows for either ICANN or the Registrar to file court proceedings regarding a dispute related to the RAA. The RAA places limits on the monetary amounts that an arbitration panel or a judge may impose on either party in a lawsuit or arbitration.

ICANN may take other compliance actions against the Registrar without resorting to termination of the RAA. For example, ICANN has the right to suspend the Registrar's ability to create new Registered Names and/or the Registrar's ability to initiate inbound transfers of Registered Names for up to one year, but only under certain circumstances. The Registrar may face suspension for a failure to cure a breach of the RAA within a proper amount of time. In addition, if a Registrar receives notices of at least three separate violations of the RAA within a one-year period, even if the Registrar cures each noticed breach within the required time frame, ICANN has the ability to suspend the Registrar from creating new registrations based on the reoccurrence of RAA violations. This suspension right is in addition to the termination provisions, though suspension is not as drastic of a compliance enforcement tool as termination.

If a Registrar is acquired by another business/entity, the Registrar must provide ICANN notice of the acquisition and provide certain information regarding the Registrar's continued ability to meet the accreditation requirements within thirty (30) days of the acquisition. If the Registrar wants to transfer the RAA to another business or entity, ICANN must agree in writing to the transfer.

3. Conclusion

The RAA is a binding legal document between ICANN and each of its accredited Registrars. The RAA is important in defining the Registrar's role in the domain name system and how the Registrar interacts with its Registered Name Holders. This Guide is provided to assist Registered Name Holders and end users in gaining a better understanding of the obligations between ICANN and the Registrars, and to give some context on how the RAA obligations affect Registered Name Holders and end users. While this Guide does not have legal effect, it represents an important step in making ICANN's work more accessible to all, and increasing a common understanding of the roles and responsibilities of all persons in the Internet Community.

4. Glossary

There are some basic terms that are helpful to understand when reading about ICANN and the domain name system (DNS). A more comprehensive glossary can be found at The general descriptions of terms here do not replace the legal definitions of terms used in the RAA, and are offered to provide assistance in reading and understanding this Guide.

ccTLD or country code top-level domain: ccTLDs are a class of TLDs (see below) that are only assignable to represent countries or territories on the ISO 3166 list. These are the two-character names, such as.DE for Germany, or.IE for Ireland. There will be additional ccTLDs in the near future, referred to as Internationalized Domain Name ccTLDs (IDN ccTLDs), which are non-Latin character equivalents and allow registration in scripts and characters local to the country, such as an Arabic representation of Saudi Arabia, or a Cyrillic representation of Russia. Registrations in ccTLDs are not subject to the provisions of the RAA.

gTLD or generic top-level domain: The class of TLDs (see below) that are used for general purposes, such as.COM or.NET. gTLDs are of two types: sponsored top-level domains, such as.JOBS or .TRAVEL, and the unsponsored TLDs, such as.COM and.NET. A sponsored TLD serves a specific community, and the registry interacts with a sponsoring organization that oversees the policy development for the operation of the sponsored TLD. The RAA applies to all registrations within gTLDs.

Name Server: A general term for a system on the Internet that answers requests to convert domain names into something else.

Registered Name Holder: The registrant of the domain name.

Registrar: An entity that acts on requests from Registered Name Holder s to make changes at the registry, including the initial registration of domain names. The RAA applies to all Registrars that are accredited to register names within gTLDs.

Registry: For the purposes of understanding the RAA, a Registry is the record of all registrations within a particular TLD.

Registry Operator: The person or entity that runs a Registry.

TLD or Top Level Domain: A TLD is the highest level subdomain in the DNS, represented by everything to the right of the “dot”, such as.COM,.UK, and.EDU. There are different classifications of TLDs, including generic TLDs (gTLD) and country code TLDs (ccTLDs).

UDRP, or the Uniform Domain Name Dispute Resolution Policy: The UDRP is a policy adopted by ICANN that is incorporated into every agreement between a registered name holder and a Registrar in a gTLD. The UDRP sets out the terms and conditions for disputes based on the registration and use of a domain name. The UDRP is posted at and is translated into 10 languages.

* The Non-Lawyers' Guide is an evolving document. ICANN staff welcomes comments and input on how the Guide can be improved.

1 The RAA does not set out this discussion on proxy/privacy registration. It is provided in this Guide to give context.

2 The UDRP is briefly described in the Glossary at the end of this Guide.

3 A graphic representation of the life cycle of a typical gTLD Registered Name is located at This diagram may be useful to refer to for more information on the post-expiration

4 There are formal technical names for domain name statuses, arising out of the community-based Internet draft Request for Comments. The statuses required here are set by the Registrar. When a registration is in one of these statuses, a domain cannot be deleted and the registration cannot be modified. The Registrar must remove the HOLD or LOCK status in order for any modification to occur.

5 There are many other potential ways to “infringe the legal rights” of others, and potential Registered Name Holders are encouraged to seek independent advice if they are concerned that the registration or use of a domain name may violate someone else's rights.

6 There could be other jurisdictions that are able to decide a dispute about the use of a registered name, but those additional jurisdictions are not specified in the RAA.

7 For examples of Consensus Policies that have been created within ICANN, see the policies identified at

8 ICANN has specific processes it follows to assist in the orderly transition of registrations in the event of a termination of a Registrar's accreditation. Further information about specific procedures can be found in the De-Accredited Registrar Transition Procedure, at [PDF, 119 KB].

9 Arbitration is a private method for dispute resolution, as opposed to the public method of filing a lawsuit in a court. Arbitrations are typically faster, more efficient proceedings than lawsuits filed in courts. Instead of being overseen by a judge, arbitration is overseen by a panel of privately-hired arbitrators, who all must be clear of conflicts of interest with the parties involved in the arbitration.

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