Skip to main content
Resources

2013 RAA | Frequently Asked Questions

Accreditation Fees

What are the fees for ICANN registrar accreditation? Annual accreditation fees are fees that all registrars are required to pay annually to maintain accreditation. Registrars have the option of paying the annual $4,000 accreditation fee in quarterly installments of $1,000.

Variable accreditation fees are determined based on the transaction type and volume of each registrar. There are two types of fees associated with the variable accreditation fees:

  • Variable fees for all registrars in the aggregate are accounted for in the ICANN org annual budget. The variable fee is divided among all registrars based on a validated concept that ICANN often expends the same quantum of effort in providing services to a registrar regardless of size. However, provided that the registrar is considerably smaller in size and in activity, some registrars will continue to be eligible for "forgiveness" of two-thirds of the standard per-registrar variable fee. To be eligible for forgiveness, the registrar must have (1) less than 350,000 gTLD names under its management and (2) no more than 200 attempted adds per successful net add in any TLD. Forgiveness will be granted each quarter to all registrars that qualify. More information about the forgiveness provision is available in the annual ICANN org budget.

    The amount of the variable fee payable per registrar is calculated each quarter by dividing one-fourth of the total fee budgeted equally among all registrars that have at least been accredited for one full quarter or have made at least one transaction, taking into consideration the forgiveness factor.

  • Transaction-based fees are assessed on each annual increment of an add, renew or a transfer transaction that has survived a related add or auto-renew grace period. This fee is billed at $0.18 per transaction for registrars operating under the 2013 RAA. More information about the transaction-based fees is available in the annual ICANN org budget.

Registrar Data Directory Service (WHOIS) Specification

  1. Does my Registrar Data Directory Service (WHOIS) response format have to follow the same order as the example in Section 1.4.2 of the RDDS (WHOIS) Specification?

    Yes. The format of responses shall contain all the elements in the provided order.

  2. The Registrar Data Directory Service (WHOIS) Specification requires me to provide a Registrar Abuse Contact Phone in my WHOIS output. Would it be okay to display the text "please contact us by email" in this field?

    No. The Registrar Data Directory Service (WHOIS) Specification requires the registrar to provide a Registrar Abuse Contact Email and a Registrar Abuse Telephone Number. An actual valid telephone number needs to be provided for the telephone field.

  3. Regarding the Registration Data Directory Service (WHOIS) Specification, the name servers of the domain name must be listed in the WHOIS records. In a case where a name server depends on the same domain name (e.g. the domain name is icann.org and one of the name servers is ns.icann.org), must a glue record be listed and in which format?

    Glue records are not required; however, registrars have the option to add more fields. Therefore, a registrar could add the IP addresses for glue data. If a registrar were to do that, it should add the fields using the format defined in the new gTLD base agreement:

    IP Address: 192.0.2.123
    IP Address: 2001:0DB8::1

  4. Section 1.4.2 of the RDDSS gives an example of compliant WHOIS output. That output shows the following DNSSEC status: DNSSEC: signed Delegation. What are the other possible values for this field?

    The two possible values are:

    DNSSEC: signedDelegation
    DNSSEC: unsigned

  5. Is DNSSEC mandatory?

    Registrars are not required to offer DNS hosting (which might or might not include DNSSEC service), but they must facilitate DNSSEC entries to the registry.

  6. What are the sanctions for Service Level Agreement failures in the RDDS Specification?

    ICANN Compliance will follow its standard procedure found here: http://www.icann.org/en/resources/compliance/approach-processes. Additionally, the registrar may be asked to provide a root cause analysis, explaining why the problem occurred and identifying short and long-term solutions.

Data Retention Specification

  1. How can I request a waiver from compliance for items in the Data Retention Specification that would violate my local laws?

    The 2013 Registrar Accreditation Agreement (RAA) includes within its Data Retention Specification (DRS) a provision by which registrars may request a waiver from compliance with specific terms and conditions of the DRS. Registrars who wish to request a DRS waiver can find the relevant form and process here: https://www.icann.org/en/resources/registrars/updates/retention.

    In addition, please make sure to indicate (a) the specific allegedly offending data collection and retention elements that you believe would violate your local law and those that would not violate your local law; (b) the specific period(s) of time that you believe retention of various data elements would and would not be permitted under your local law; and (c) the specific provisions of your local law that you believe would be violated.

  2. Can I submit a data retention waiver request on behalf of my back-end provider or reseller(s)?

    Registrars may submit a data retention waiver request on behalf of third parties, and ICANN will review the requests on a case-by-case basis. The request(s) must come through the registrar itself; requests from non ICANN-accredited registrars will not be evaluated by ICANN.

  3. Am I required to retain the data in the event of a change to the registration data, or is it acceptable to collect required information only at the time of registration?

    Changes to registration data must be retained.

  4. Is my reseller responsible for retaining data?

    While registrars may outsource some of the requirements of the RAA to resellers, please note that the registrar is ultimately responsible for compliance with the RAA. If ICANN observes that a reseller is not in compliance with the RAA or any ICANN consensus policy, ICANN would commence its compliance inquiry directly with the sponsoring registrar (not the reseller).

  5. If a registrar is only offering new gTLDs, is the registrar required to offer WHOIS via Port 43?

    The registrar will only have to provide Port 43 access for thin registries. For all registries, including new gTLDs, the registrar is still required to provide web-based access.

Posting and Disclosure Requirements

  1. Does the abuse point of contact need to be on my homepage or can it be on a page to which the homepage links? Is a "Contact Us" page okay for this requirement?

    The abuse point of contact needs to be conspicuous and readily accessible for those that need to search for it. The rationale for using the term "homepage" is so that the email for the abuse point of contact is not buried under several links. From an ICANN Compliance perspective, it would not be a problem to have a link from the main page that goes to a second page. It does, however, need to be conspicuously posted on the registrar's site. It cannot, for example, be behind a log in page or sub-linked down several pages that would require a number of clicks. It would be best if the contact is on the main page or a second page accessible by a link prominently displayed on the main page.

    If the link to the "Contact Us" page is readily accessible on the registrar's homepage and includes the abuse point of contact (et. al.), that would be compliant under the 2013 RAA.

  2. Is it OK if we expose a link to a contact form to reach the abuse desk, rather than expose the email address?

    No. Section 3.18.1 provides that an actual email address needs to be provided. Providing a contact form would not be compliant under the 2013 RAA.

  3. Do we need to post names of all of our officers on our website(s)?

    Further to Item 17 of the Registrar Information Specification, officer names and positions must be published on the registrar's website. Officer email addresses are not required to be posted to the registrar's website. All items of the Registrar Information Specification that have an asterisk (*) next to them must be published on the registrar's website.

  4. How is officer defined?

    The definition of officer will depend on what constitutes an officer for a corporation or other entity under the law of the registrar's jurisdiction.

  5. Do I have to maintain a unique law enforcement contact, or can a law enforcement contact be shared among registrars?

    The email address and telephone number do not have to be unique, but they must be monitored 24 hours per day and 7 days per week. Additionally, well-founded reports of abuse must be responded to within 24 hours further to Section 3.18.2 of the RAA.

  6. Do website disclosures apply irrespective of the registrar business model? For example, if we operate on a purely reseller basis (i.e. all registrants purchase through resellers), do the website disclosures still need to be made?

    Yes. Website disclosures must be made irrespective of the registrar's business model.

  7. We are required to make our renewal fees, post-expiration renewal fees (if different), and redemption/restore fees reasonably available to registered name holders and prospective registered name holders at the time of registration of a gTLD name. How are we expected to comply with this obligation when the registration is made through a reseller? We do not set resellers' prices as this would be illegal.

    There are a number of ways registrars could comply with this provision of the Expired Registration Recovery Policy (ERRP). ICANN does not dictate a specific process your registrar must use. We have provided some suggestions below, which you might wish to consider:

    • Include all of the ERRP reseller obligations in the agreement between your registrar and its resellers and attach consequences for contractual non-compliance.
    • Implement monitoring processes whereby your registrar periodically looks at its resellers' websites to be certain they are allowing your registrar to maintain compliance with ERRP obligations.
    • Include annual reporting requirements in the agreement between your registrar and its resellers that would require resellers to provide evidence that they are in compliance with the ERRP obligations and other RAA obligations.

    If ICANN observes that a reseller is not in compliance with an ICANN consensus policy, such as the ERRP, or any provision of the RAA, ICANN would commence its compliance inquiry directly with the sponsoring registrar (not the reseller).

    It would be acceptable for the registrar/reseller to post the highest fee it would charge for renewal/redemption as fees may be different depending on the business model, i.e., discounts for bulk registrations or other factors determined by the registrar.

  8. Section 3.17 of the RAA states that Information related to registrars needs to be published on the website as per the Registrar Information Specification. What information from the Specification needs to be published on our website?

    The items from the Registrar Information Specification that need to be published on the registrar's website are:

    • Item 7, the correspondence address for the registrar;
    • Item 11 (If the location or address of registrar's principal place of business is different from the address provided in 7, provide details including address, phone number, fax number, and email address);
    • Item 17, officer names and positions; and
    • Item 22 (list the ultimate parent entity of the registrar, if applicable)

    All other information in the Registrar Information Specification must be submitted to ICANN as per 3.17 of the RAA, but it does not have to be published on the registrar's website.

  9. Section 3.7.11 of the RAA provides that registrars shall make available a description of the customer service handling processes available to Registered Name Holders regarding Registrar Services, including a description of the processes for submitting complaints and resolving disputes regarding the Registrar Services. How much detail must this process include?

    ICANN will validate that a description of the Customer Service Handling Process is available to the public on a registrar's website(s) in which a registrar offers Registrar Services, or whether it is provided upon request. The Customer Service Handling Process must contain sufficient detail to qualify as a valid Customer Service Handling Process.

  10. Section 3.18.2 provides that well-founded reports of Illegal Activity submitted to the registrar must be reviewed within 24 hours by an individual who is empowered by the registrar to take necessary and appropriate actions in response to the report. In responding to any such reports, the registrar will not be required to take any action in contravention of applicable law. What does "well-founded" mean?

    ICANN will consider this on a case-by-case basis, taking into account factors such as substantiation, demonstration, corroboration or evidence of Illegal Activity, but cannot specify in any particular circumstance what qualifies as "well-founded" as that may vary based upon the situation. If the registrar believes the request is not "well-founded," it should document the reasons for this decision.

Resellers

  1. Section 3.12 of the RAA requires me to maintain written agreements with my resellers. Would a digital signature be okay for this requirement?

    The answer to this question depends on the law of the registrar's jurisdiction. If, for example, the registrar's jurisdiction recognizes digital signatures as legally enforceable, a digital signature would be acceptable for this requirement of the RAA.

  2. Section 3.12.6 provides that I must use "commercially reasonable efforts" to enforce reseller compliance. Can you provide an example of commercially reasonable efforts?

    The list below is a non-exhaustive list of examples that would be evidence that the registrar is enforcing its agreement with the reseller:

    • Include all of the reseller obligations in the agreement between your registrar and its resellers and attach consequences for contract non-compliance
    • Implement monitoring processes whereby your registrar periodically looks at its resellers' websites to ensure compliance with certain RAA obligations (such as website posting requirements)
    • Include annual reporting requirements in the agreement between your registrar and its resellers that would require resellers to provide evidence that they are in compliance with RAA obligations

WHOIS Accuracy Program Specification

How would registrars demonstrate compliance for manual or verbal verifications?

ICANN will require a written confirmation of verbal verifications, such as an email or note indicating with whom the registrar spoke as well as the date, time, phone number, and a description of the substance of the conversation.

2013 RAA Webinars

Where can I find links to 2013 RAA webinars?

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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