Home / Blogs

How to Improve WHOIS Data Accuracy

A major concern about the present WHOIS is the level of data inaccuracy. The Expert Working Group (EWG) on Registration Directory Service (RDS), of which I had the pleasure of being a member, spent considerable time figuring out how to improve WHOIS data accuracy. The EWG in its final report proposed a new system, the RDS, which we believe will significantly address the flaws in the current WHOIS, including the data inaccuracy challenge. There were two basic approaches adopted towards improving WHOIS data accuracy. The first was to create necessary measures that give incentives to contact holders (Registrants and Purpose Based Contacts) to input accurate data in the system. The second was to device a mechanism to detect inaccurate data when inputted in the system.

Incentives for Registrants to input accurate data in RDS

The RDS offers a lot of benefits that should put registrants worried about privacy at ease. It makes it harder for criminals to access sensitive data by putting all sensitive data behind a series of “gates” which are only accessible to authenticated users with permissible purposes. Registrants are able to control their own personal data. They determine which data they want behind each gate and which data can be publicly displayed to anonymous requestors. Registrants are also able to designate third-parties (Purpose Based Contacts) to assume responsibilities for certain tasks on their behalf. This takes some burdens away from the registrant and transfers it to others who are qualified and willing to take over that responsibility on their behalf. Updating contacts is greatly simplified. The system allows contact holders to easily update their data and such updates to be automatically applied to every affected domain own by the registrant. This is not possible with today’s WHOIS. The increase in privacy and the ease of updating contacts makes it less likely for contact holders to intentionally supply invalid data.

Mechanisms to detect invalid data (The Validators)

While these RDS changes might incentivize contact holders to supply more accurate data, my colleagues and I realized that some contact holders may still opt to or unintentionally enter inaccurate data in the system. There must be a mechanism to detect such entries. This led us to propose a new kind of contracted party: The validators.

What is a validator?

Validators would specialize in collecting, validating, and storing contact data (postal address, email address, phone, fax, SMS numbers, etc.) which shall be made available by the RDS only to authorized requestors. Validators could be new third-party operators or registrars or registries—any organization that is willing and able to perform RDS contact data validation services in accordance with contractual requirements.

In the proposed RDS, a contact holder would interface with its chosen validator to enter its data elements. For example, I might decide to create a contact for myself using a validator in my own country, entering my addresses and telephone number through a local-language user interface. Once I created a contact with my own data, the validator assigns a unique ID to that contact data. A registrant is not limited to having just one contact ID. You can create many contacts if you wish. You might have different contacts for personal and business roles. You could then use that contact in many domain name registrations, purchased from any registrar and gTLD registry, anywhere in the world.

Covering validation costs

Obviously, validators incur expenses when checking the syntax and operational accuracy of each email address, telephone number, and postal address. But as specialists in checking data accuracy, validators may reuse existing tools, focus on data formats or languages in a given geographic area, and/or benefit from economies of scale.

Unless they chose to become a validator, registrars and registries wouldn’t have to reinvent or buy validation tools. During domain name registration, they could just take the contact IDs supplied by each registrant and retrieve already-validated contact data from validators. If a new domain name registrant hadn’t yet created validated contact(s), they could be referred to and handled by a validator in real-time, so that registration could be completed without delay.

It was beyond the EWG’s scope to recommend how validators would be compensated, but there are many possible business models. Some registrants might prefer to pay their choice of validator to create a block of new contacts. Over time, as contacts are reused in many domain name registrations, the number of new contacts that must be created will be far smaller than the number of domain names, reducing overall validation cost to the entire ecosystem.

Is validation too great a burden?

Some people argue that validation is just too costly. Because my EWG colleagues and I knew that cost was a big concern, we looked for ways that validation might be delivered more cost-effectively. We also believe that accurate data would likely benefit everyone who wastes considerable time and effort trying to use invalid WHOIS data.

I have heard criticisms that the proposed RDS validation would delay domain name registration, forcing registrants to go somewhere to create a contact and wait for validation before that contact could be used. This is simply not what we proposed. Rather, we suggested a process where quick automated checks would be conducted in real-time, and any optional requested checks that involve delay occur after the contact is created, with a feedback loop to overcome any detected inaccuracies.

Finally, some people confuse the concept of dedicated validators with another option proposed by the EWG: optional identity validation. Again, this is a misreading of our report. The EWG did not propose that identity validation be required, or that contacts be forced to show government IDs or any other proof of identity when creating a contact. In fact, our final report supports use of contacts created by accredited privacy and proxy services, so that registrants would still have the option of not entering their own contact data, instead designating a third party willing to serve as a contact for that domain name.

I hope this clears up a few questions and misunderstandings about the EWG’s proposed RDS validator ecosystem. My EWG colleagues and I look forward to working with the community to explore this validator proposal and possible benefits to improve the quality of WHOIS data.

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix


Sponsored byVerisign

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global