Skip to main content
Resources

ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR

The 2013 Registrar Accreditation Agreement (RAA) requires registrars to take steps to ensure the accuracy of registration data associated with their sponsored gTLD domain names. In particular, the RAA includes obligations relating to the investigation of allegations of inaccuracy, contact information verification, and data format validation.

ICANN organization (org) enforces these and other RAA obligations through its Contractual Compliance team. This report highlights the relevant enforcement actions and how they have been impacted by the Temporary Specification for gTLD Registration Data (Temporary Specification) and the Interim Registration Data Policy for gTLDs (Interim Policy). The Temporary Specification was adopted to comply with the European Union's General Data Protection Regulation (GDPR), which went into effect on 25 May 2018.

Data accuracy obligations and ICANN org's enforcement of these obligations have not changed post-GDPR. However, the volume of complaints has diminished significantly concurrent with personal registration data becoming unavailable following adoption of the GDPR. ICANN org and potential complainants now lack direct access to registration data as a result of the GDPR, making it much more difficult to identify instances of registration data inaccuracy or to take action to correct them.

Contractual Requirements Concerning Data Accuracy

Within 15 days of the registration or inbound transfer of a domain name, or a change to the registrant information, a registrar must 1) validate that the data format is correct per the applicable country or territory standard(s) ("validation"); and 2) verify the email address or the telephone number of the registrant and the account holder (if different) by sending a communication and requiring an affirmative response in a manner designated by the registrar ("verification"). If the registrar does not receive an affirmative response from the registrant, it must verify the information manually or suspend the registration until it can verify it. If the registrar has previously validated or verified the same information and it is not in possession of facts or knowledge of circumstances that suggest that it is no longer valid, it is not required to take further action. Specific references can be found in the WHOIS Accuracy Program Specification.

Upon being notified of an inaccuracy in the contact information associated with a domain name sponsored by a registrar, the registrar must take reasonable steps to investigate and, where applicable, correct the inaccuracy.

If the registrar has any information suggesting that the contact information is inaccurate, the registrar must validate, verify, or re-verify the registrant's information. If the registrar does not receive an affirmative response from the registrant within 15 days, the registrar must verify the contact information manually or suspend the registration until the verification is completed.

Further, upon the occurrence of a registrant's willful provision of inaccurate information, or its failure to update the information or respond to accuracy inquiries within 15 days, the registrar must terminate or suspend the domain name registration or place it on clientHold and clientTransferProhibited until the data can be confirmed.

GDPR and Adoption of the Temporary Specification and Interim Registration Data Policy

On 25 May 2018, GDPR became effective across the European Union countries. On 17 May 2018, the Temporary Specification established temporary requirements to allow ICANN and its contracted parties to continue to comply with ICANN policies and agreements in a manner that does not conflict with the GDPR. The Temporary Specification maintained the existing WHOIS system to the greatest extent possible but restricted most personal data to layered or tiered access.

The 20 May 2019 Interim Registration Data Policy for gTLDs (Interim Policy) requires that contracted parties continue to implement measures that are consistent with the Temporary Specification, pending the implementation of a permanent Registration Data Policy.

Neither the Temporary Specification nor the Interim Registration Data Policy modified the RAA requirements for registrars to validate and verify registrant contact information and to investigate claims of inaccuracy.

Enforcement of the Data Accuracy Requirements

ICANN org ensures that contracted parties fulfill their contractual obligations and comply with community-developed policies. Contractual Compliance undertakes enforcement actions resulting from complaints received from external users, proactive monitoring, and audit-related activities.

Upon receiving a complaint alleging a registration data inaccuracy, Contractual Compliance confirms that:

  • The complaint is within ICANN org's contractual scope (e.g., it refers to a matter addressed by an ICANN policy or agreement and to a party over whom ICANN org has enforcement authority).
  • The complainant provides evidence of the claimed inaccuracy (e.g., a bounce-back or returned "undeliverable" email or post) or the inaccuracy is evident in the WHOIS (e.g., the telephone number listed is "123").

Complaints that fall outside of ICANN org's contractual scope or lack evidence of noncompliance are closed. Contractual Compliance sends an explanation of the closure reasons as well as alternative avenues to pursue to each complainant. For those that remain open, Contractual Compliance initiates an investigation into the registrar's compliance with the contractual requirements explained above, including the obligation to take reasonable steps to investigate the claimed inaccuracy.

The "reasonability" of the steps will depend on the type of inaccuracy reported. For example, a report of a nonfunctional email address may only require the registrar to perform email verification to ensure the email is functioning. However, if the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint.

Contractual Compliance will typically close an inaccuracy case when the registrar demonstrates compliance with the investigation and validation or verification requirements, which may include the suspension or cancellation of the domain name registration. The registrar's failure to demonstrate compliance results in escalation through the Contractual Compliance process, which may include the issuance of a public breach notice and that may also may result in the suspension or termination of the registrar's RAA.

Addressing Complaints Before GDPR

From January 2017 to May 2018, Contractual Compliance received a monthly average of 2,774 complaints related to the accuracy of the registration data. During this period, Contractual Compliance closed a monthly average of 1,599 out-of-scope complaints. See Figure 1 below.

Average Monthly Totals of Data Inaccuracy Registration Complaints and those Deemed Out-Of-Scope (Jan. 2017 - May 2018)

Figure 1: Average Monthly Totals of Data Inaccuracy Registration Complaints and Those Deemed Out-Of-Scope (Jan. 2017 - May 2018)

From January 2017 to May 2018, Contractual Compliance initiated 20,834 investigations into registrars' compliance with registration data accuracy obligations: 16,357 in 2017 and 4,477 from January 2018 to May 2018. These investigations resulted from both external complaints and proactive monitoring activities such as the WHOIS Accuracy Reporting System (ARS) project.

During the same time period, Contractual Compliance initiated 20,834 investigations and closed 21,569 investigations into registrars' compliance with registration data accuracy. Some of the complaints closed during a reporting period were received in a prior reporting period (e.g., received in December 2016, closed in January 2017). This is why the number of closed complaints is larger than the number of complaints received during the reporting period. In 79% of the cases, the registrar had suspended or canceled the domain name registration; in 15% of the cases, the inaccurate data was updated; and in 3% of the cases, the registrar provided evidence that the data was correct. All other cases represented the final 3%. See Figure 2 below.

Reasons Why Data Inaccuracy Investigations Were Closed (Jan. 2017 - May 2018)

Figure 2: Reasons Why Data Inaccuracy Investigations Were Closed (Jan. 2017 - May 2018)

The vast majority of the investigations were resolved within the informal resolution phase.

Eight public breach notices were issued to registrars who failed to demonstrate compliance with their registration data accuracy obligations. Of those:

  1. Two escalated to RAA suspension (one of them resulting in a subsequent voluntary termination)
  2. Two escalated to RAA termination
  3. Four were cured

Addressing Complaints After GDPR

From June 2018 to December 2020, Contractual Compliance received a monthly average of 1,003 complaints. During this period, Contractual Compliance closed a monthly average of 745 out-of-scope complaints. See Figure 3 below.

Average Monthly Totals of Data Inaccuracy Registration Complaints and Those Deemed Out-of-Scope (June 18 - Dec. 2020)

Figure 3: Average Monthly Totals of Data Inaccuracy Registration Complaints and Those Deemed Out-of-Scope (June 18 - Dec. 2020)

The decrease in complaint volume from a monthly average of 2,774 pre-GDPR to 1,003 post-GDPR resulted from a significant reduction in external complaints and from ICANN org no longer releasing WHOIS ARS reports beginning in June 2018.

In addition, the percentage of complaints received that lacked evidence of noncompliance or fell outside of ICANN org's contractual scope increased. For example, many complainants believe that the registration data is "missing" from the public Registration Data Directory Service (or WHOIS service), privacy or proxy service data are redactions, or all non-European data should be displayed. While Contractual Compliance efforts to educate complainants on contractual requirements increased, the number of actual investigations into registrars' compliance with registration data accuracy obligations decreased.

After GDPR, Contractual Compliance began to request, where applicable, additional evidence of the claimed inaccuracy, such as details regarding the source of the data where the nonpublic information is redacted. Contractual Compliance initiates an investigation where the evidence is provided.

From June 2018 to December 2020, Contractual Compliance initiated 4,417 investigations into registrar compliance with registration data accuracy obligations (1,860 from June 2018 to December 2018; 2,030 in 2019 and 527 in 2020). During the same time period, Contractual Compliance closed 4,567 investigations into registrars' compliance with registration data accuracy. Some of the complaints that were closed during a reporting period were received in a prior reporting period. This is why the number of closed complaints was larger than the number of complaints received during the reporting period. In 69% of the cases, the registrar suspended or canceled the domain name registration; in 26% of the cases, the inaccurate data was updated; and in 3% of the cases the registrar provided evidence that the data was correct. All other cases represented the final 2%. See Figure 4 below.

Figure 4: Reasons Why Data Inaccuracy Investigations Were Closed (June 2018 - Dec. 2020)

Figure 4: Reasons Why Data Inaccuracy Investigations Were Closed (June 2018 - Dec. 2020)

While the number of investigations initiated decreased considerably after GDPR, the outcomes for those investigations were quite similar to those conducted pre-GDPR. During both periods, the majority of complaints resulted in the suspension of the domain name(s), followed by a significant percentage in which the data was corrected.

Post-GDPR, no formal breach notice has been issued concerning registration data accuracy obligations.

ICANN org understands the importance of access to accurate data for Internet users, including registrants, law enforcement, intellectual property owners, and cybersecurity researchers. We enforce and will continue to enforce our contractual agreements and the community's policies concerning registration data accuracy. Our ability to enforce these obligations depends on awareness of the existence of inaccurate data through the receipt of external complaints (supported by evidence of inaccuracy) and through our own proactive monitoring activities. As a result of GDPR, potential complainants and Contractual Compliance now lack direct access to registration data. It is therefore not surprising that post-GDPR, the volume of registration data inaccuracy complaints has dropped almost 65% on an average monthly basis.

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