As a result of the IANA Stewardship Transition, you may find some site content that is out of date. Please use the “Feedback” button in the bottom right corner of the page if you have questions or discover content that requires updating.

Registrant Rights and Responsibilities Under the 2009 Registrar Accreditation Agreement

This page is available in:

Registrant Rights and Responsibilities Under the 2009 Registrar Accreditation Agreement

Background: One of the new provisions added to the 2009 RAA requires ICANN to develop in consultation with registrars a webpage that identifies available registrant rights and responsibilities. This published document is the result of initial input from a joint working group of the GNSO Council and the At-Large Advisory Committee and subsequent consultations with the registrars; and provides a "plain language" summary of registrant rights and responsibilities that currently exist under the 2009 RAA.

Introduction

This document provides some "plain language" summarization of terms related to Registrant Rights and Responsibilities as set out in the Registrar Accreditation Agreement (RAA), for posting on Registrar websites. While some of the terms included here do not specifically refer to registrants, those terms are included because of the potential import to understanding registrar/registrant relations. This document also summarizes registrant rights and responsibilities that arise within ICANN Consensus Policies and specifications, as those policies and specifications are incorporated into the RAA.'

The summarization of terms within this document do not override or replace the terms set forth in the RAA or within those specifications or policy.

Preamble

In order to register a domain name, a Registered Name Holder (also known as a Registrant) has to use the services of an ICANN-accredited Registrar. In order to become an ICANN-accredited Registrar, the Registrar must enter into a contract with ICANN, referred to as the Registrar Accreditation Agreement or the RAA. The RAA sets out various rights and responsibilities for Registrants, and Registrants have additional rights and responsibilities that are set forth in separate ICANN policies and specifications that the Registrars agree to follow.

The RAA and the related policies are drafted in very specific, often legal terminology. In order to help Registrants better understand the rights and responsibilities that come along with the registration of a domain name, these rights and responsibilities are being summarized and presented within a single document. The summaries provided here do not override or replace the actual terms as written in the RAA or the related policies and specifications.

RAA Terms of Interest

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 breach of the RAA.

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

Some of the Registrar obligations are dependent upon Registered Name Holders fulfilling certain responsibilities, particularly as it relates to payment of registration fees, submission of required data points to the Registrars, and submission of accurate data and timely updates to that required data. 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 notices regarding escrowing of data for domain names registered through privacy or proxy registration services, as well as the posting of fees for the recovery of registered names.

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:

Unless automatically generated by the registry system, the identity of the Registrar (3.2.1.4);

Unless automatically generated by the registry system, the expiration date of the registration (3.2.1.5); and

Any other data the Registry Operator requires be submitted to it (3.2.1.6).

Registered Name Holders are normally required to provide the Registrar with information relating to nameservers (3.2.1.2 – 3), and there may be additional data required under Section 3.2.1.6 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.

Whois Data

Registrars are required to have an interactive web page and port 43 Whois service that is 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 name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name (3.3.1.7); and

The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name (3.3.1.8).

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.

The RAA allows 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 access for high volume queries or other restrictions on uses of Whois data as specified in the RAA, including marketing activities and mass solicitations. If a Registrar contracts the public function query to an outside party, the Registrar must require any contractor providing the port 43 service to impose the same restrictions on access to and use of the Whois 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.

In some instances, a registrant may choose to limit the amount of personal information that a Registrar makes available in a Whois query. To do so, the name may be registered through a privacy service (allowing a registrant to conceal personal identifying information and often replacing it with the information of the privacy service). Customers may also choose to register names through a proxy service, where the proxy service is the Registered Name Holder, and the proxy service licenses the use of the domain name to the customer. In that situation, the proxy service, as the Registered Name Holder, has its information listed for most or all required data points.

When a Registered Name is registered through a privacy or proxy registration service, that affects the information that is placed in the database, and a Registrar must do one of two things: The Registrar must either (1) include in the database the name and postal address, e-mail address, and voice telephone number provided by the customer in connection with each registration, even when a privacy or proxy registration is used; 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 may only be sent to the contact information within the database.

A registrar may not activate a Registered Name until it receives reasonable assurance from the Registered Name Holder that the registration fee will be paid.

The RAA sets forth 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 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 right for the Registrar to cancel the registration and the obligation to the delete the domain name is not absolute. Section 3.7.5.1 of the RAA sets forth a list of potential "extenuating circumstances," that, if exist, allows 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 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.

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,2 and must modify the Whois information to show that the name is subject to dispute. Section 3.7.5.7 of RAA also provides for a right for the original domain name registrant 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 domain name registrant.

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 3.7.7.1.: "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 an Registered Name Holder that is an organization, association, or corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8."

If a Registered Name Holder intentionally provides inaccurate or unreliable information, intentionally fails to promptly update the information, or fails to respond over 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 discloses the user’s identity and current contact information.

The Registrar must provide notice of how it intends to use data provided by the Registered Name Holder and who will received 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 violates a trademark or copyright held by someone that is not the Registered Name Holder.3

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 in at least one of two places: where the Registrar is located (often stated on the website or in the Registrar/Registered Name Holder Agreement) or 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 those locations have the power to decide these types of cases.4

The Registered Name Holder must agree that its registration is subject to "suspension, cancellation, or transfer" for the reasons stated in Section 3.7.7.11. 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 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 should be posted on the Registrar’s website.

Reseller arrangements

The RAA imposes obligations on Registrars working with third-party Resellers – persons or entities that the Registrar contracts with to provide Registrar Services. The RAA now 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) posts 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.

Other Policies/Specifications

The Restored Names Accuracy Policy (http://www.icann.org/en/registrars/rnap.htm) requires that when a registrar restores a name (from the redemption grace period) that had been deleted on the basis of submission of false contact data or non-response to registrar inquiries, the name must be placed on Registrar Hold status until the registrant has provided updated and accurate Whois information.

In addition to the RAA requirement that a Registered Name Holder represent that to the best of its knowledge, the registration or use of the domain name does not infringe on the legal rights of others, the Uniform Domain Name Dispute Resolution Policy ("UDRP") requires that same representation to be made, as well as a representation that the domain name is not being registered for an unlawful purpose, and will not be used in violation of any applicable laws.

The UDRP also requires Registered Name Holders to submit to mandatory administrative proceedings to resolve disputes under the UDRP. These mandatory administrative proceedings, as described in the UDRP, are disputes that are filed before one of the ICANN approved UDRP dispute resolution providers (listed at http://www.icann.org/en/dndr/udrp/approved-providers.htm) and following the uniform Rules for UDRP administrative proceedings (set out at http://www.icann.org/en/dndr/udrp/uniform-rules.htm). The requirement for submission to mandatory administrative proceedings does not mean that Registered Name Holders cannot also have judicial proceedings filed against them for the same or similar conduct. Similar to the jurisdictional requirements set out in the RAA, the requirement to submit to a mandatory administrative proceeding means that the Registered Name Holder cannot dispute the UDRP provider’s ability to hear a dispute that is otherwise properly brought under the UDRP.

The Policy on Transfers of Registrations between Registrars provides that Registered Name Holders have the right to transfer domain name registrations among registrars. The transfer policy imposes time limits on when the Registrar must respond to a transfer request. The right to transfer is not absolute – there are ICANN and Registry policies that may set limits on the transfer right, including: limitations on when a domain name may be transferred (measured from dates of creation or earlier transfer); and the Registered Name Holder providing of required authorization and documentation for Registrar review. The Registrar of Record may only deny a transfer in the following instances:

Evidence of fraud

UDRP action

Court order by a court of competent jurisdiction

Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact

No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.

Express written objection to the transfer from the Transfer Contact. (e.g. - email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means)

A domain name was already in "lock status" provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status.

The transfer was requested within 60 days of the creation date as shown in the registry Whois record for the domain name.

A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs).

2 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, the domain cannot be deleted and the registration cannot be modified. The Registrar must alter the status in order for any modification to occur.

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

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

ICANN is not responsible for profile content or verification of user details.

A note about tracking cookies:

This notice is intended to appear only the first time you visit the site on any computer.Dismiss

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