Latest news of the domain name industry

Recent Posts

Universal Acceptance – making the internet work for everyone [Guest Post]

Kevin Murphy, March 24, 2021, Domain Tech

Editor’s note: this is a guest post written by Aman Masjide, head of compliance at new gTLD registry Radix.

Back in 2014, to foster innovation and to better the choice in domain names, ICANN introduced new generic top-level domains through its New gTLD Program. It was a monumental move that enabled businesses, individuals, and communities across the globe to mark their presence on the internet.

Allowing users to be present digitally in their chosen language (non-ASCII characters and scripts) gave opportunities to local businesses, civil societies, and governments to better serve their communities.

Analysys Mason conservatively estimates that there is scope of $9.8 billion growth in potential revenue from both; existing users who are using new domain names and from new internet users coming online through Internationalized Domain Names (IDNs).

To achieve this, Universal Acceptance of new gTLDs and IDNs is critical in making the Internet more accessible to the next billion users. Founded in February 2015, the Universal Acceptance Steering Group (UASG) undertakes activities to promote Universal Acceptance of all valid domain names and email addresses.

Through its ambassadorship and local Initiative programs, UASG promotes Universal Acceptance globally. Their efforts are divided and executed through five working groups that include:

  • Technology Working Group
  • Email Address Internationalization Working Group
  • Communications Working Group
  • Measurement Working Group
  • Local Initiatives Working Group

Before we get into the acceptance of new domain extensions (nTLDs), we must first understand what acceptance means and how it’s measured.

The Universal Acceptance Steering Group’s mission sums up acceptance in one short statement: “All domain names and all email addresses work in all software applications.”

While this is a simple understanding of the concept, for an end user of an nTLD, this statement further branches out into multiple questions such as:

  • Will my domain name work on all platforms/applications–online or offline?
  • Will my email address on a new domain extension get accepted on all websites/platforms and pass all the validation tests?
  • Will my emails on new domain extensions, once accepted, stop going into the junk folder?
  • Will I be able to use all the features of a website/platform irrespective of my domain extensions? For example, will a social media platform accept a new domain extension in the bio, comments, posts, messenger, etc, and process it exactly like any other legacy TLD?

The Universal Acceptance (UA) of all domain names and email addresses requires that every piece of software is able to accept, validate, process, store, and display them correctly and consistently.

As a new domains registry, it was critical for us to understand what the gaps were and how to close them so that the internet operates the same for nTLD users as it does for the legacy TLD users.

Initial research concluded that UA readiness issues occur when applications are not able to handle the following categories of a domains name or email addresses:

Domain Names

  • New short top-level domain names: example.fun, example.site
  • New long top-level domain names: example.berlin, example.space
  • Internationalized Domain Names: παράδειγμα.ευ

Email Addresses

  • ASCII@ASCII; new short or long TLD: ekrem@misal.istanbul
  • ASCII@IDN: john@société.org
  • Unicode@ASCII: 测试@example.com
  • Unicode@IDN: ईमेल@उदाहरण.भारत
  • Unicode@IDN; right to left scripts: لیم@لاثم.عقوم ای

For Universal Acceptance to succeed, it needs to be examined holistically.

Over the years, UASG working group members have conducted several gap analysis on programming languages and frameworks, networking command-line tools, web browsers, websites, and have made great strides in acceptance of new domain extensions.

According to UASG’s FY 2020 report, tests conducted on top websites showed that

  • The acceptance rate of emails on short nTLDs has increased from 91% in 2017 to 98.3% in 2020.
  • The acceptance rate of emails on long nTLDs has increased from 78% in 2017 to 84.8% in 2020.

table

Note: The table above compares the 2020 results to the earlier 2017 and 2019 testing results.

Two important caveats should be remembered in this case:

  • Different email addresses were tested (but they were of the same type).
  • The websites tested in 2020 were different from previous ones as they were the 50 most popular in the 20 countries rather than the 1,000 most popular globally.

However, these results may still be used to compare overall trends.

Universal Acceptance Readiness Report 2020 (pdf) also segregated test websites as per different categories such as eCommerce, government, education, etc and the results were promising.

table

Such studies help UASG ambassadors and advocates to identify and focus on websites of a specific category that require immediate attention. We conducted a similar study at Radix where we analysed top websites belonging to different categories. These were the results (click to enlarge):

table

While the acceptance rates for new short and new long cases is more than 80% under most categories, we see a drastic dip when a domain is on an IDN TLD. Such comparisons highlight problem areas and provide direction to ambassadors and members who are advocating for Universal Acceptance.

Radix’s contribution to UASG

UA is something that affects nTLD users the most. This is why it’s crucial to focus on the feedback that we receive from them. At Radix, we work closely with our users to ensure we have the first hand information on any UA related issues faced by the customer.

The feedback could be about linkification, validation or acceptance of emails on nTLDs on different websites and platforms. Radix also actively invests its resources in gap analysis by testing various websites and social media platforms. We are also part of the ambassadorship program promoting and supporting local and global UA initiatives.

Here are some of the UASG initiatives that Radix is part of:

At Radix, our objective is to ensure that nTLDs are accepted across websites and platforms. To achieve this, we actively work with UASG and share as many issues and gaps noticed and reported by customers.

Contribution by other registries

A key objective for most registries is to ensure great customer experience when it comes to their nTLDs and I’ve always admired it when registry operators have actively taken initiative and participated in the five UASG groups mentioned above.

One of the ways to do this is to capture all the queries and complaints reported by their customers/registrar partners and share it with UASG. This will help their support team direct their resources in solving the problems and encouraging those websites to become UA compliant.

Contribution by registrars

When it comes to UA-related issues, registrars are the first in chain to receive a complaint or feedback from the user. Therefore, it’s crucial that their support teams have all the necessary information needed on how to best handle such complaints.

For now, they can:

  • Inform the customer about the potential UA issue and raise a request on behalf of the customer with UASG. Issues can be logged at – https://uasg.tech/global-support-center/
  • Report these instances to the Registry Operator so that they can connect and follow up with UASG.
  • Join any of the five working groups and participate.

The path ahead

The UASG is consistently compiling and sharing all the important information needed for organizations and developers to become UA ready. This is not only about ensuring the readiness of a system to accept certain TLDs or emails, but also about realising the full potential of an organization by connecting with people and businesses that might not be even on it’s radar.

Every successful step taken by an organization towards UA readiness is also a step towards equality and inclusiveness on the internet.

Guest poster Aman Masjide leads compliance and abuse mitigation at Radix.

After 20 years, DomainTools takes its first VC dough

Kevin Murphy, December 3, 2020, Domain Tech

DomainTools has taken a “significant” investment from a venture capital firm, the first outside funding its received in its 20-year history.

The amount of the investment is undisclosed, but DomainTools said its investor is Battery Ventures.

Battery already owns stakes in numerous software and technology companies, but this appears to be its first foray into the domain name space.

Its principal, Jordan Welu, and partner Dave Tabors will join DomainTools’ board of directors and Andy Rothery, a Battery “executive-in-residence”, will become its executive chairman.

DomainTools said in a press release:

This investment will drive more rapid innovation in DomainTools’ platform capabilities for machine learning-based threat analytics and predictive risk scoring, along with enhanced product development around automating threat intelligence and incident response workflows.

The company is all about the “threat intelligence” nowadays, no doubt partly due to the fact that its original mission of aggregating the world’s Whois data will become decreasingly useful in light of privacy laws such as GDPR.

As a private company its financial position is unknown, but I’ll note that it did take a big chunk of change out of the US taxpayers’ pocket earlier this year under a government coronavirus-related corporate-relief program.

Coronavirus could cause “high risk of widespread outages”, ICANN says

Kevin Murphy, April 21, 2020, Domain Tech

There’s a “high risk of widespread outages” in the DNS if ICANN can’t get enough people in the same room for its next root DNSSEC ceremony because of the coronavirus pandemic.

That’s according to ICANN’s own board of directors, which yesterday published a contingency plan that — in the worst case scenario — could see parts of the internet come to a screeching halt in July.

The problem is with the elaborate “ceremonies” that ICANN and its IANA/PTI unit uses to make sure the internet can support DNSSEC — the secure version of the DNS protocol — all the way from the root servers down.

Every quarter, ICANN, Verisign and a select few “Trusted Community Representatives” from all over the world meet in person at one of two secure US-based facilities to generate the public Zone Signing Keys for the root.

In addition to the complex cryptographic stuff happening in the computers, there’s a shedload of physical security, such as retinal scans, PIN-based locks, and reinforced walls.

And the “secret key-holders”, memorably fictionalized in a US spy drama a few years ago, actually have physical keys that they must bring to these ceremonies.

The events are broadcast live and archived on YouTube, where they typically get anything from a few hundred to a few thousand views.

Obviously, with the key-holders dotted all over the globe and most under some form of coronavirus-related lockdown, getting a quorum into the same facility at the same time — originally, Culpeper, Virginia on April 23 — isn’t going to be possible.

So IANA has made the decision to instead move the ceremony to the facility in El Segundo, California, within easy driving distance of ICANN’s headquarters, and have it carried out almost entirely by ICANN staff, wrapped in personal protective equipment and keeping their distance from each other.

The TCRs for El Segundo live in Mauritius, Spain, Russia, Tanzania, Uruguay and on the east-coast of the US, according to ICANN.

Four of these key-holders have mailed their keys to different IANA staff “wrapped in opaque material” and sealed in “tamper-evident bags”. These IANA employees will stand in for the TCRs, who will be watching remotely to verify that nothing fishy is going on.

Verisign and the independent auditors will also be watching remotely.

That’s the current plan, anyway, and I’ve no reason to believe it won’t go ahead, but ICANN’s new contingency plans do provide four alternatives.

It’s already discarded the first two options, so if the current, third, plan for the ceremony can’t go ahead before June 19 for some reason, all that would be left is the nuclear option.

Option D: Suspend signing of the DNS root zone

This is the final option if there is no conceivable way to activate the KSK and perform signing operations. There would need to be a massive education campaign at short notice to have resolver operators disable DNSSEC validation. There is a high risk of widespread outages as it is not possible to ensure global implementation, and high risk this will fatally compromise trust in DNSSEC in general as a technology.

This is considered highly unlikely, but nonetheless the final option. Without exercising the option, in the absence of a successful key signing ceremony, DNSSEC validation would be unsuccessful starting in July 2020.

The reason for this scenario is that DNSSEC keys have a finite time-to-live and after that period expires they stop functioning, which means anyone validating DNSSEC on their network may well stop resolving the signed zones.

ICANN typically generates the keys one quarter in advance, so the current key expires at the start of July.

However, the planned April 23 ceremony will generate three quarters worth of keys in advance, so the root should be good until the end of March 2021, assuming everything goes according to plan.

Clearly, the idea that half the planet might be on the verge of lockdown wasn’t taken into consideration on February 12, the last ceremony, when ICANN’s biggest problem was that it couldn’t get into one of its safes.

If you’re interested in more about the ceremony and the coronavirus-related changes, info can be found here.

Go here to help fight against coronavirus abuse

Kevin Murphy, March 26, 2020, Domain Tech

A coalition of over 1,000 security experts, domain name providers and others have got together to help coordinate efforts to combat abusive coronavirus-related domains.

A workspace on the collaboration platform Slack has been growing steadily since it was created a week ago, enabling technology professionals to exchange information about the alarming number of sites currently trying to take advantage of the pandemic.

You can join the channel via this link. Thanks to Theo Geurts of RealtimeRegister.com for passing it along.

The collection of chat rooms appears to have been created by Joshua Saxe, chief scientist at security software firm Sophos, March 19. There are currently 1,104 members.

There’s a channel devoted to malicious domains, which is being used to share statistical data and lists of bad and good coronavirus-related domains, among other things.

Across the workspace, a broad cross-section of interested parties is represented. Current members appear to come from security companies, governments, law enforcement, registries, registrars, ICANN, healthcare providers, and others.

It seems like a pretty good way for the technical members of the domain name industry to keep track of what’s going on during the current crisis, potentially helping them to put a stop to threats using domains they manage as they emerge.

DI Leaders Roundtable #2 — Should we kill off “Whois”?

Kevin Murphy, November 11, 2019, Domain Tech

Should we stop using the word “Whois” to describe registration data lookup services?

That’s the question I posed for the second DI Leaders Roundtable.

I’m sure you’re all very well aware that the Registration Data Access Protocol (RDAP) is the imminent replacement for the Whois protocol, as the technical method by which domain registrant contact information is stored, transmitted and displayed.

ICANN also regularly refers to Registration Data Directory Services (RDDS) as a protocol-independent blanket term covering the concept of looking up Whois or RDAP data.

You may also recall that ICANN, which is ostensibly a technical body, appears to bedeprecating the word “Whois” in favor of “Lookup” on its own web-based query service.

ICANN has a track record of introducing new acronyms to describe already well-understood functions. The IANA has technically been called “Public Technical Identifiers” for years, but does anyone actually call it “PTI”? No, everyone still talks about “IANA”.

So I wanted to know:

Should we continue to call it “Whois” after the technical transition to RDAP is complete? Will you continue to refer to “Whois”? Should we change to a different word or acronym? Should the industry standardardize its language one way or the other?

There seems to be a general consensus that “Whois” ain’t going anywhere.

The responses, in no particular order.

Jothan Frakes, Executive Director, Domain Name Association

Mugshot

The term WHOIS won’t quickly leave the zeitgeist due to the decades of its use as a description of the lookup process. Lookup is somewhat confusing, as there is DNS Query lookup that works across the resolution system, and WHOIS Lookup that works to find registrant info via the registration system. As far as the term “Lookup” as the label for the new normal that is poised to replace WHOIS? It is better than the acronym “RDDS”. The general public probably would not assume that RDDS is a way to find out about a domain owner or registration information, because it sounds like it involves dentistry (DDS) if one is not following the ICANN world as close as insiders. Despite the evolutionary path the basic function seems to be on, it is likely that WHOIS continues to be what the nickname for the lookup process called, regardless of the support technology layers below it not literally being WHOIS.

Frank Schilling, CEO, Uniregistry

Mugshot

WHOIS IS DEAD, LONG LIVE WHOIS.

The echo of “Whois” will live long after Whois is dead and gone. The very nature of its replacement word “Lookup” ensures that the information hungry public will expect more fulsome data than ICANN intends the word to provide. There will continue to be services who try to engineer a Whois hack and provide accurate underlying data for paying customers. Whois is going to outlive all of us. Even those who diet, exercise, and eat organic food.

Dave Piscitello, Partner, Interisle Consulting Group

MugshotJust as most of the world isn’t familiar with new TLDs, most have no appreciation for the differences between Whois and RDAP. The term “Whois” is convenient, memorable, and embedded. It also represents a service to most users, not a protocol, so if we do “standardize” we should use “RDS”. While we sort out the disastrous effects of ICANN’s Temp Spec policy on both investigators and victims of DNS abuse, most parties involved with educating policy makers and legislators should continue to use Whois for consistency’s sake.

Christa Taylor, CMO, MMX

MugshotAs the old adage goes, “Don’t fix what’s not broken.” While “Whois” may have lost some of its luster due to GDPR I prefer to retain the term — it’s simple, representative of the information it provides and avoids adding any confusion especially for people outside of ICANN. Employing standardized language is, of course, logical and after twenty years of using “Whois” it is the accepted term both inside and outside the industry.

Sandeep Ramchamdani, CEO, Radix Registry

MugshotFirst up, the transition to the RDAP system is much needed given the fundamental flaws of Whois.

It would help in placing some guardrails around customers’ privacy while still providing agencies such as law enforcement authenticated access that they need to do their work.

Whois is a major cause of spam and in the age where privacy is top currency, public, unauthenticated availability of personal data is unacceptable.

It should also smooth out inter-registrar transfers and lower customer frustration while moving out to a different service provider.

When it comes to its name, calling it “RDAP” or “Lookup” would be a branding error. It would cause some confusion and for those not intimately involved in the industry, who may find it hard to discover the new system.

In my mind, keeping the original nomenclature “Whois”, while making it clear that it’s a newer avatar of the same solution would be the way to go.

Can’t think of a better term than “Whois 2.0”.

Very easy to understand that it’s a newer, more advanced iteration of the same product.

Michele Neylon, CEO, Blacknight

Mugshot

Whois was originally a simple little protocol that allowed network operators to contact each other to address technical issues. It predates the usage of domain names or the “web”.

When domains were introduced the same concept was simply transposed over to the new identifiers.

However over the past 20 plus years the way that people viewed Whois has morphed dramatically. The first time I spoke at an ICANN meeting 12 years ago was on the subject of Whois!

Now the term is used both to talk about the technical protocol, which is being replaced in the gTLD space and the data that it is used to store and possibly display. We talk about “Thin Whois”, “Thick Whois” and so many other services and issues linked back to it.

Whois as a protocol is far from perfect, which is why replacing the technical side of it makes a lot of sense.

So with the world slowly moving towards a new technical method for processing domain registration data then maybe we should come up with another word for it. However I’m not sure if there’s much to be gained by doing that.

We are all used to the floppy disk icon to save a document, even if floppy disks are no longer used. With the term “Whois” being part of people’s vocabulary for the nearly a quarter of a century. it’d be pretty hard to find a simple replacement and have people adopt it widely. Sure, in the more technical conversations it makes sense to use more accurate terms like “RDAP”, but the average punter just wants to be able to use a term that they can understand.

Those of us who work with domains and internet technology in our day jobs might care about the “correct” terminology, but we’re in a minority. We all get excited when the mainstream media picks up on a story involving domain names or the DNS and even gets half of it right! If we conjure up some new term that we think is accurate it’ll take years before anyone outside our bubble is comfortable with it. So I don’t think we should.

We should simply accept that “Whois” is a term used to refer to domain registration data no matter what technology under the hood is used to handle it.

Rick Schwartz, domain investor

MugshotHate to give the same basic answer to two questions in a row, but who cares?

Really!! Who cares? Nobody!

This is inside baseball that doesn’t affect anyone on the entire planet except for a handful of domain investors and ICANN etc.

Call it whatever you like just make sure it’s public info.

Emoji domains get a 😟 after broad study

Kevin Murphy, October 28, 2019, Domain Tech

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.

The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.

The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.

It’s 30 pages long, and you can read it here (pdf).

Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.

But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.

That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.

Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.

The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:

Emoji comparison

If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.

There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.

In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.

Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.

ICANN enters talks to kill off Whois for good

Kevin Murphy, October 23, 2019, Domain Tech

Whois’ days are numbered.

ICANN is to soon enter talks with accredited registrars and contracted gTLD registries with the aim of naming a date to finally “sunset” the aging protocol.

It wants to negotiate amendments to the Registrar Accreditation Agreement and Registry Agreement with a view to replacing obligations to publish Whois with obligations to publish Registration Data Access Protocol data.

In letters to the chairs of its registrar and registry constituencies this week, ICANN CEO Göran Marby wrote:

The primary focus of the amendment is to incorporate contractual requirements for the Registration Data Access Protocol (RDAP) into the Registration Data Directory Services. This should include definition of the plan and provisions to sunset the obligations related to the WHOIS protocol as we transition Registration Data Services to RDAP.

For avoidance of doubt, people will still be able to look up the contact information for domain name owners after the change, but the data they see (very likely redacted for privacy reasons nowadays) will be delivered over a different protocol.

The contract amendment processes involve both registry and registrar constituencies to nominate a few people to engage in talks with ICANN negotiators, which is expected to conclude within 90 days.

When they come up with mutually acceptable language, the amendments will be open for both public comment and a vote of registries and registrars, before going to the ICANN board of directors for final approval.

The voting process is complex, designed to avoid capture by the largest registrars, and based on a balance of the number of voting registrars and the number of domains they collectively manage.

The contractual changes will come as no surprise to contracted parties, which have been on-notice for years that Whois is on its way out in favor of RDAP.

Most registrars already operate an RDAP server in parallel to their old Whois service, following an ICANN deadline in August.

We could be looking at the death of Whois within a year.

More than 1,000 new gTLDs a year? Sure!

Kevin Murphy, September 5, 2019, Domain Tech

There’s no particular reason ICANN shouldn’t be able to add more than 1,000 new gTLDs to the DNS every year, according to security experts.

The Security and Stability Advisory Committee has informed ICANN (pdf) that the cap, which was in place for the 2012 application round, “has no relevance for the security of the root zone”.

Back then, ICANN had picked the 1,000-a-year upper limit for delegations more or less out of thin air, as a straw man for SSAC, the root server operators, and those who were opposed to new gTLDs in general to shake their sticks at. It was concluded that 1,000 should present no issues.

As it turned out, it took two and a half years for ICANN to add the first 1,000 new gTLDs, largely due to the manual elements of the application process.

SSAC is now reiterating its previous advice that monitoring the rate of change at the root is more important than how many TLDs are added, and that there needs to be a way to slam the brakes on delegations if things go titsup.

The committee is also far more concerned that some of the 2012 new gTLDs are being quite badly abused by spammers and the like, and that ICANN is not doing enough to address this problem.

Paranoid ICANN opens another root server in China

Kevin Murphy, September 5, 2019, Domain Tech

ICANN has announced the creation of another root server instance in China, which definitely, DEFINITELY won’t let the Chinese government mess with the interwebs.

ICANN said this week that it’s opened an instance of the L-root that it manages in Shanghai.

It’s the third L-root in China but only the first outside of Beijing.

In a press release announcing the installation, which was carried out with technical support from CNNIC and Shanghai Telecom, ICANN decided to preemptively head off any concerns that putting an important piece of internet infrastructure in China comes with added security risk:

Contrary to common misconception, root servers do not control the Internet. The operation of an instance also does not provide any mechanism to alter content of the DNS. Any modification of root zone content will be mitigated by a part of the DNS protocol known as the DNS Security Extensions (DNSSEC) and if an instance fail to respond to a query, resolvers will ask the same question to another instance or root server.

It’s merely the latest of 168 L-root installations and 1,015 copies of the 13 logical root servers, which all use IP Anycast to more quickly serve DNS answers to their local users.

Given how big and populous China is, there are surprisingly few root server instances in the country, according to root-servers.org.

In addition to ICANN’s three boxes, Verisign’s J-root and Internet Systems Consortium’s F-root have three in Beijing and two in Hangzhou between them. The K, I and F roots each have one instance in Beijing.

That’s eight nodes in China proper, which has 800 million internet users. Cross the border into semi-autonomous Hong Kong, which has a population of under eight million people, and there are nine root instances.

The city of Bucharest, Romania (pop. 1.8 million) has the same number of root instances as China.

ICANN dumps the “Whois” in new Whois tool

Kevin Murphy, July 31, 2019, Domain Tech

Of all the jargon regularly deployed in the domain name industry and ICANN community, “Whois” is probably the one requiring the least explanation.

It’s self-explanatory, historically doing exactly what it says on the tin. But it’s on its way out, to be replaced by the far less user-friendly “RDAP”.

The latest piece of evidence of this transition: ICANN has pushed its old Whois query tool aside in favor of a new, primarily RDAP-based service that no longer uses the word “Whois”.

RDAP is the Registration Data Access Protocol, the IETF’s standardized Whois replacement to which gTLD registries and registrars are contractually obliged to migrate their registrant data.

Thankfully, ICANN isn’t branding the service on this rather opaque acronym. Rather, it’s using the word “Lookup” instead.

The longstanding whois.icann.org web site has been deprecated, replaced with lookup.icann.org. Visitors to the old page will be bounced to the new one.

The old site looked like this:

Whois

The new site looks like this:

Whois

It’s pretty much useless for most domains, if you want to find out who actually owns them.

If you query a .com or .net domain, you’ll only receive Verisign’s “thin” output. This does not included any registrant information.

That’s unlike most commercial Whois services, which also ping the relevant registrar for the full thick record.

For non-Verisign gTLDs, ICANN will return the registry’s thick record, but it will be very likely be mostly redacted, as required under ICANN’s post-GDPR privacy policy.

While contracted parties are still transitioning away from Whois to RDAP, the ICANN tool will fail over to the old Whois output if it receives no RDAP data.

Under current ICANN Whois policy, registries and registrars have until August 26 to deploy RDAP services to run alongside their existing Whois services.