|
Today, anyone can use WHOIS to identify the organization or person who registered a gTLD domain name, along with their postal address, email address, and telephone number. Publishing this data has long been controversial, creating a system riddled with problems. On one hand, anonymous access to all WHOIS data enables misuse by spammers and criminals and raises concerns about personal privacy. On the other hand, incomplete or false WHOIS data prolongs Internet outages and leaves crime victims with little recourse.
While previous efforts to repair WHOIS have helped somewhat, a comprehensive fix was never attempted. And coming on the expansion of the domain namespace with new gTLDs,we cannot meet the needs of the evolving global Internet by simply patching this fundamentally-flawed system. We must work together as a community to create a better solution. The Expert Working Group (EWG) on next-generation Registration Directory Services (RDS) was formed to take a fresh look at registration data needs and address the challenges identified.
What is the RDS?
In our June 2014 Final Report, my colleagues and I proposed a brand new system that we believe is significantly better than today’s WHOIS. While no system is perfect, our proposed RDS strikes a balance between accuracy, privacy, and accountability to better serve the global Internet community. We believe there is something good in this for every stakeholder.
As the EWG considered the needs and concerns of WHOIS users, registrants, registries, and registrars, we concluded that giving everyone the same anonymous public access to all gTLD registration data should be abandoned. Instead, we recommended a new RDS to collect, validate and disclose data for permissible purposes only, with some values remaining public and others being gated—that is, disclosed only to authorized users who identify themselves, state their purpose, and agree to be held accountable.
We readily admit much work remains to flesh out policies and implementation details before the RDS could replace WHOIS. But in the same way we were informed from work that went on before us, we are unanimous our output is a worthwhile platform from whence these efforts can be energized. This is not a simple problem; the RDS is not a simple answer. However, my EWG colleagues and I believe the proposed RDS could help our community overcome WHOIS failures by creating that which benefits all stakeholders—including individual domain name registrants.
How does the RDS benefit individual registrants?
Critics argue that the RDS benefits only “the big guys”—businesses that register many domain names, intellectual property owners, large registrars and registries, etc. Yes, these stakeholders benefit, but so do “the little guys”—individuals, small businesses, and others who register just one domain name.
Delivering balanced benefits for ALL—including individual registrants—was top of mind for the EWG. We believe our proposed RDS achieves this in many ways.
1) If the RDS replaces WHOIS, registrants will have more visibility into what their data is used for.
Today, WHOIS data is collected from registrants without providing insight into why this data is needed or who will use it. Unlike larger registrants, individuals have little knowledge of DNS operation, how Internet failures are resolved, or how Internet crime is deterred. The RDS would explicitly describe these and other permissible purposes when data is collected, giving individuals greater visibility into what data will be used for, and greater appreciation of why some contact data is essential for every domain name.
2) Registrants and their designated contacts can enter and update their data more easily.
Today, data is collected every time a domain name is registered—including technical and administrative contacts needed to resolve problems. Often, those contacts are web hosting firms, ISPs, or registrars. WHOIS requires every registrant to enter and update addresses for those contacts—leading to stale, inaccurate data. But the RDS would collect addresses directly from each contact just once. Registrants would simply enter contact IDs—unique numbers assigned to each contact. Every time a contact updates his or her address, those changes would automatically apply to all domain names using that ID. This requires far less data entry and maintenance from registrants while increasing overall accuracy.
3) Registrants will have more flexibility and control over what data is public.
Today, all WHOIS data is public—forcing individuals to use privacy or proxy services if they want to avoid publishing their personal addresses or names in the WHOIS. The RDS would make public the bare minimum dataset: domain name details, contact IDs for the registrant and designated contacts, and the registrant’s own email address. By default, all other contact data would be gated—that is, accessible only to authorized users with permissible purposes. Registrants and contacts can choose to make more data public, but would not be required to do so. For example, an individual registrant might make public only his or her email address, designating an ISP as their domain name’s contact. That ISP might opt to publish its phone number and URL. This makes it easier to directly reach those responsible for resolving problems, while letting registrants publish less personal information.
4) Registrants and their contacts will have options to deter fraudulent use of their data.
Today, any value can be entered into WHOIS—including the name and address of another person or business, without their knowledge or permission. In fact, individuals may be victims of WHOIS identity fraud and not even know it! The RDS would perform basic validation of contact data—for example, requiring each registrant’s email address to be correctly formatted and live. In addition, the RDS offers optional identity validation—a service that any individual or business can choose when creating a contact to prevent others from using their name or address without permission.
5) Registrants will have one place to access their data to see what RDS users can learn about them.
Today, WHOIS data is accessible through a hodgepodge of registry, registrar, reseller and third-party systems, leaving registrants without any single place to check what WHOIS says about them. Conceptually, the RDS would provide a single portal to process registration data queries, giving each registrant direct access to every bit of data that the RDS makes available to anyone, for any purpose. If questions arise about the accuracy or use of that data, the RDS provides a single interface through which to submit complaints for investigation and remediation. This approach greatly simplifies problem resolution for individual registrants who simply do not have the resources or DNS expertise to track down and deal with every WHOIS provider.
6) Registrants will have greater assurance that privacy, data protection, security, and auditing policies will be applied.
Processing all data queries through the RDS also makes it possible to uniformly enforce global policies intended to ensure personal privacy, comply with applicable data protection laws, safeguard registration data storage and transfer, authenticate users to prevent unauthorized access, and audit access to detect and deter any inappropriate use. Without a system like the RDS in place, there is little hope of accomplishing these goals—practices and policies are far too diverse and distributed among parties with varying levels of expertise and rigor. With the RDS, individual registrants can know that someone is responsible for meeting these needs, and can easily reach them.
7) Access to each Registrant’s data will be limited to those with a need to know, and requestors who access data will be held accountable for proper use.
Finally, in today’s WHOIS, entirely anonymous access makes it hard to identify or prosecute criminals that misuse that data. The RDS places most registration data—including nearly all contact names and addresses—behind a series of gates. No gated data would be returned unless the requestor identifies themselves and states a purpose for the requested data, demonstrating they are who they claim to be and have a legitimate need to know. Some purposes are likely to have a “lower bar”—for example, technical contact data may be readily accessible to nearly everyone. Other purposes will have a “high bar” and be very closely monitored by the RDS for signs of abuse, triggering quick action to block and hold violators accountable for misuse. Individual registrants have much to gain from a WHOIS replacement that respects their personal privacy in this manner.
My EWG colleagues and I realize that our Final Report is quite lengthy and detailed—a response to community requests for more details on our proposals and as it had to be in order to thoroughly explore and recommend a solution to such a complex and challenging topic. However, to make it easier for everyone to learn more about the proposed RDS, we also recorded a series of brief video FAQs.
I encourage you to learn more about the RDS and how it could benefit YOU.
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byVerisign
You say that a comprehensive rework has never been attempted. This is not strictly true.
I, for example, proposed a very comprehensive rework, including protocol changes in the early 2000s, called “WIRE.” It was soundly rejected by registrars. The larger ones felt it gave too much control away. The smaller ones complained that they didn’t have the resources to code up and enact a new system. Both politics and business played into the proposal falling completely flat.
Yet it contained pretty-much all the points being proposed these days as well.
An idea before it’s time, perhaps? ;)
I think the problem is that most of these proposals are long on specifications and short on implementation. They rely on parties (like the registrars) who won't gain any benefit to spend the money and do the hard work of implementing the protocol. You'd gain far more traction if along with the specification came a reference implementation, eg. a RESTful XML-based service that handled the database and implemented the access rules and could be called easily by the registrar's system to retrieve and update the information.
Totally agreed.
At the time, I was working for eNom, and I did, in fact, create and provide a reference implementation. It was still rejected for the reasons I outlined.