Tiered Access update: registration data accuracy, and updated statistics

In the lead-up to ICANN74, we’re back with another set of Tiered Access disclosure request and response statistics. You can jump to the numbers to see how the first few months of 2022 compared to previous years. Since the Registration Data Accuracy Scoping Team is focusing on the topic, we’d like to provide some insight into how registrars know the data they’re disclosing via systems like Tiered Access are accurate.

How do registrars ensure that registration data are accurate?

It’s important for domain registrars that the registration data associated with domain names under their management is accurate and up-to-date. We need to know who owns the domains that are registered with us—that is, who we have a contractual relationship with—and ensure that only the true owner has control over the domain. It also ensures that messages about the domain—such as renewal reminders and notifications of domain compromise or potential abuse—are sent to the domain owner.

The accuracy of registration data is especially important for the Tucows family of registrars because we operate primarily through a reseller network: our most direct relationship is with our reseller, not with the registrant themselves. For situations where we must reach out to the registrant directly, it is imperative that we have the right information in the domain contact since we usually don’t have access to the registrant’s billing or account contact information.

There are several processes and requirements in place to help maintain the accuracy of registration data.

First, the domain name registrant has responsibilities under our Registration Agreement (which ICANN requires we pass on to the registrant): they are required to provide accurate and up-to-date contact information and to update the domain record promptly if their contact information changes.

Then, domain registrars must validate and verify that contact information. This happens every time a new contact set is used, either on a brand new domain or when updating the data for an existing domain name.

Validation is a set of automated checks that ensure that all the required data has been provided and that it matches the expected format. For example, phone numbers and postal addresses must be validated against industry standards (like the UPU), while email addresses must match the format documented in RFC 5322. On our platforms—and many others—the system automatically compares inputs against these standards to ensure that the data passes validation requirements before it can be saved on a domain name.

Verification is a semi-automated process, where the registrar sends a confirmation to the registrant via email or SMS and they must affirmatively respond within 15 days; if they do not, the domain is suspended until the verification is completed. This helps ensure that every registrant is contactable and provides working contact information for their registration record. Because the purpose of this verification is to ensure contactability, it’s only necessary to verify domain contact info the first time it’s provided; if identical verified data is used on another domain, the registrant does not need to re-verify this data for any additional domains they register.

There’s also a process in place to remind registrants to keep their information current: registrars must send an annual message for each domain, reminding the registrant what their registration data is and how to update it if it is no longer correct. If the data is still accurate, no action needs to be taken. If that email is not successfully delivered, the verification process is automatically triggered; again, the registrant has 15 days to complete verification before their domain is suspended.

With these validation and verification requirements in place, we know that we’re starting from a solid baseline of accurate contact information and maintaining it over each domain name’s lifetime.

How we address Whois inaccuracy

We rely on self-reporting of data—we don’t knock on registrants’ doors to make sure that they actually live or work at the address they’ve provided. We don’t send postcards to people to make sure that the address actually exists. Partly because at the large scale the Internet operates on, this is impossible to do; partly because this would be very creepy; and partly because it wouldn’t necessarily get us information that’s any better than what we already get—how often do you carefully review all the bulk mail you receive to your physical address every day?

We do, however, have a duty to maintain the accuracy of registration data over time and we recognize that when someone moves to a new home, updating their domain name is probably not at the top of their to-do list. In addition to sending the annual reminder to update their information, we also reach out to registrants directly if we have reason to suspect that their information is inaccurate. Typically, this is because of a report: someone looked up the information in a public Whois record and found some defect with the data they were provided. If the registrant fails to confirm or update their information, we suspend the domain until they do.

It’s important to note that information may be correct even if a registrant ignores mail sent to them or does not answer the phone—in fact, there are scams designed specifically around the public Whois records, taking advantage of people’s fear of losing a domain name to extort money.

Registrants can choose to make their Whois Information public but most opt not to have their personal data published on the Internet. To aid in finding and resolving instances of inaccurate Whois data, we are building a form into our TACO system that allows a disclosure requestor to report inaccurate Whois directly from the lookup results page. We hope this will help increase requestor trust in the data we provide through TACO.

If you have any questions, suggestions, or comments about the processes outlined above, please reach out to us. Now: onto the numbers!


Tiered Access Statistics, January – April 2022

 

Data disclosure request outcomes

Below, you’ll find a breakdown of disclosure request outcomes for this year so far, followed by a detailed comparison between outcome rates for this period and previous years.

Tucows received 148 domain data disclosure requests between January 1 and April 30, 2022; this brings us up to 4797 total requests since we began tracking in January 2018.

Disclosure request outcomes: New Period (Jan 1 – April 30, 2022)



Request outcomes from 2018 – 2021 and new period, compared

The disclosure rate for registration data for the first part of 2022 is on track with the rate from 2021. We noted that incomplete or abandoned requests and requests associated with Whois-Privacy-protected domains both dropped, while denied requests increased.

Disclosure rates



Abandoned request rates



Denied request rates



Requests for data associated with privacy-protected domains



Requests by requestor category

We noted an increase in law enforcement requests during period 1 of 2022. We can attribute this specifically to an increase in requests from one specific foreign law enforcement agent (LEA) requestor, who investigates financial fraud in their jurisdiction. This particular requestor is a long-time regular who consistently submits correctly-formatted requests for previously-public registration data, underlining the reasonability of our requirements and ease of compliance with them. We don’t know why financial fraud—or financial fraud investigations—may have increased in their particular jurisdiction, but we do know this increase in our numbers is directly attributable to this specific requestor.

Requests by category for new period

Requests by category since the launch of TACO



Abandon rates by requestor type



Total requests over time

We look forward to seeing you at ICANN74, whether in person or virtually, and we remain available to discuss our experiences with the Tiered Access platform and disclosure request process.

To read our past Tiered Access blog posts, please see: